On Jun 28, 2010, at 10:09 AM, Michael Hertling wrote:
> On 06/28/2010 05:24 AM, Tom Birch wrote:
>> CMake's dependency scanner uses its own parser to scan for #include
>> directives, and then builds up the dependency tree this way. I know it's
>> possible to rig up an invocation of gcc -M to generate the correct
>> dependencies, and then feed this into the OBJECT_DEPENDS property of source
>> files, but that means that dependency generation would happen when running
>> 'cmake .', not 'make'.
>
> One compelling reason why dependency scanning is delayed until building
> time is that it's taking dynamically generated files into account, i.e.
> files not being present at configuration time. Look at the following
> CMakeLists.txt:
>
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(DYNDEP C)
> FILE(WRITE ${CMAKE_BINARY_DIR}/f.h "void f(void);\n")
> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "\#include \"f.h\"\nvoid f(){}\n")
> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c.in
> "\#include \"f.h\"\nint main(void){f(); return 0;}\n"
> )
> ADD_CUSTOM_COMMAND(
> OUTPUT main.c
> COMMAND cp main.c.in main.c
> DEPENDS ${CMAKE_BINARY_DIR}/main.c.in
> )
> INCLUDE_DIRECTORIES(".")
> ADD_EXECUTABLE(main ${CMAKE_BINARY_DIR}/main.c ${CMAKE_BINARY_DIR}/f.c)
>
> After cmaking, when running make, the dependency of main.c.o on f.h is
> figured out, and this couldn't be achieved during the configuration as
> main.c doesn't exist at that time.
Heh, you are always the one to answer my questions!
In this case, something in the makefiles has to generate the dependencies for
this generated .c file, and today that is cmake's dependency scanner. I'm
arguing that this could be replaced by gcc -M or the platform-specific
equivalent. Most makefile-based buildsystems do this today.
>> I guess the bigger question here is: why doesn't cmake use gcc -M internally
>> when it's available? It's vastly superior to any homegrown parser, so why
>> not use it?
>
> My assumption is: As gcc or other tools for dependency scanning like
> makedepend are not available or desired on all systems supported by
> CMake there's a need for an in-house solution, at least as fallback,
> and if you once have to provide such a solution why not using it
> thoroughly? Besides, this reduces the dependencies on external
> programs - one of CMake's strengths.
That is true, but CMake has to know how to invoke various different compilers,
and generate various different project files (XCode, VC++, etc). Since gcc (and
every gcc-compatible compiler) supports -M and VC++ supports /showIncludes, why
can't CMake present an abstraction to the user that does correct dependency
discovery? Is there really another mainstream compiler out there which doesn't
support this kind of dependency generation, that outweighs the benefits of
generating dependency lists in a robust, foolproof manner?
Tom
>
> Regards,
>
> Michael
> _______________________________________________
> 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
_______________________________________________
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
