Considering the following example build.ninja:

rule sort
  command = cat input.txt | sort > output.txt

build output.txt: sort input.txt 

build foo: phony output.txt
build bar: phony output.txt

and its associated input.txt:

5
2
4
3
1

Running any of the following command succeed:

rm -f output.txt && ninja -w dupbuild=err
rm -f output.txt && ninja foo -w dupbuild=err
rm -f output.txt && ninja bar -w dupbuild=err

This indicates that having these two phony rules may not be the issue:

build Slicer: phony bin/Slicer.app/Contents/MacOS/Slicer
build SlicerApp: phony bin/Slicer.app/Contents/MacOS/Slicer

This is confirmed by skipping the launcher configuration in the application:

diff --git a/Applications/SlicerApp/CMakeLists.txt b/Applications/SlicerApp/CMakeLists.txt
index 1acd8ec..dd535ae 100755
--- a/Applications/SlicerApp/CMakeLists.txt
+++ b/Applications/SlicerApp/CMakeLists.txt
@@ -56,7 +56,7 @@ slicerMacroBuildAppLibrary(
 # Configure launcher only for the main application
 set(extra_args)
 if(${PROJECT_NAME} STREQUAL ${Slicer_MAIN_PROJECT})
-  set(extra_args CONFIGURE_LAUNCHER)
+#  set(extra_args CONFIGURE_LAUNCHER)
 endif()

 set(APP_SRCS

In that case, we still have the same two phony rules but no complain from ninja.

The second line is the one ninja identified in the error message. Here is some related discussion: https://github.com/ninja-build/ninja/issues/931

It's actually a bit trickier than just -wdupbuild=warn, because that flag doesn't automatically get threaded down to the sub-builds; there's a reason ninja devs don't like nested projects : (

I think export NINJAFLAGS=-wdupbuild=warn will work, but right now I can't access the computer where I started the build that way. doesn't work, had to build ninja locally and revert the change.

In that case, we still have the same two phony rules but no complain from ninja.

Do you think ninja is reporting the wrong line number? Or this is a CMake bug?

This sample project allows to reproduce the problem https://gist.github.com/jcfr/7e342d8ff786b82ff81873a96f66a292#gistcomment-2673574

Thanks. So my understanding is that ninja is correct here, but only one of the phony lines is the problem, because we really do have an alias duplicating a real target.

One possible work-around: invert the order. Make add_custom_target depend only on the CTKAppLauncher_EXECUTABLE. Then change the command to add_custom_command(TARGET Configure{...}Launcher POST_BUILD. I think the end result should be the same, and it seems to work, see diff in comment:

https://gist.github.com/jcfr/7e342d8ff786b82ff81873a96f66a292#gistcomment-2673734

[edit: posted wrong link above]

Suggested workaround makes sense.

Here is also the fix I suggested for the Ninja generator: https://gitlab.kitware.com/jcfr/cmake/commit/00a94baa695bcf951c0b6b8ce48617655cf97f54

MR submitted to upstream CMake. See https://gitlab.kitware.com/cmake/cmake/merge_requests/2276

I will implement the workaround in Slicer

also, we may have to add workaround in other place ... see https://github.com/Kitware/SlicerSALT/issues/44

Great. btw I guess the work-around is technically equivalent to just removing the add_custom_command and putting the COMMANDs in add_custom_target -- add_custom_target runs for every build, so the add_custom_command does too.

Fix (along with test) merged into app launcher: https://github.com/commontk/AppLauncher/commit/445c93b4043e80ee8efc5c65a2b4d47322e34408

(Before doing a new a release of the launcher, gonna have to create a new static build tree of Qt so that QProcess::setInputChannelMode is available. See https://github.com/commontk/AppLauncher/pull/101#issuecomment-411918208)

Fixed in r27469
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=27469