Tim Kientzle wrote:
Tim Kientzle wrote:
I'm having trouble with a custom target that
depends on another custom target defined in a
subdirectory. Here's a much-simplified version
of what I'm trying to do:
Turns out the subdirectory is a red herring.
Here's a much simpler demonstration of the bug:
$ cat CMakeLists.txt
PROJECT(foobar C)
ADD_EXECUTABLE(foo foo.c)
ADD_CUSTOM_TARGET(run_foo DEPENDS foo COMMAND foo)
ADD_CUSTOM_TARGET(run_all DEPENDS run_foo)
$ make run_all
[100%] Built target foo
Scanning dependencies of target run_foo
foo
[100%] Built target run_foo
Scanning dependencies of target run_all
make: don't know how to make run_foo. Stop
*** Error code 2
Unfortunately, my original message with the
background went astray.
The above is a much-simplified version of a problem
I've been struggling with. The CMakeLists.txt
above generates something that works fine with
Visual Studio (the "run_all" target does "run_foo"
as expected with no errors). But if I use a
Makefile generator (on FreeBSD 8, in this case),
then I see the strange behavior above: The
run_foo target does get run (the "foo" string
is output from the compiled foo.c) and the build
then fails being unable to locate run_foo as
a dependency of run_all.
Having skimmed the Makefiles produced by CMake,
I'm pretty sure this is a bug in how the generator
organizes the makefiles; it puts dependency information
in places where it can't possibly work.
Cheers,
Tim
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
