Hendrik Sattler <p...@hendrik-sattler.de> writes:
> >IMO that feels just wrong. foo.c does NOT depend on tab.h, foo.c does
> >not depend on anything, it's not even generated by the build system.
> >*I* edit it. Instead, it is the object file foo.o that depends on
> >tab.h.
> This is not quite correct.
Obviously, we have different definitions of "depends on". My use of
the term (and IMO that's the common meaning of "depends on" in build
systems) means "is generated from". That is, when I say a depend on
b, that means the a has to be recreated when b changes. As far as I
have read (admittedly not very much yet) in the cmake doc and
tutorial, that terminolgy is also use in cmake. For example as Craig
writes,
set_source_files_properties(foo.c PROPERTIES OBJECT_DEPENDS bar.h)
means that the object generated from foo.c depends on bar.h, and not
that foo.c depends on bar.h.
> Either your code generates a header file to be included by foo.c,
> then foo.c depends on it.
Not with the usual use of "depends on". See above.
> Or it creates data and methods that need to be linked, then the
> executable depends on it.
Yes, but not directly. The executable depends on the object file, and
the object file depends on the (created) source file. Since "depends
on" is transitive, the executable also depends on the source file.
Still, I would prefer to write add_executable(foo foo.o) and have
cmake determine that foo.o depends on foo.c like in make.
> OTOH, table-driven CRC is usually not that complicates to integrate.
Of course, it was just a simple experiment to how to deal with
generated sources in cmake. Using set_source_files_properties() it
looks quite OK:
cmake_minimum_required(VERSION 3.0)
project(simple)
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/tab.c
COMMAND awk -f ${CMAKE_SOURCE_DIR}/mktab > ${CMAKE_BINARY_DIR}/tab.c
)
include_directories(${CMAKE_BINARY_DIR})
set_source_files_properties(crc.c PROPERTIES OBJECT_DEPENDS
${CMAKE_BINARY_DIR}/tab.c)
add_executable(foo foo.c crc.c)
add_executable(bar bar.c crc.c)
> CMake handles lots of compilers that REQUIRE other object file
> extensions than .o. It also generates for more that only make,
> allowing better working with IDEs. These bring their own strange
> rules that you cannot match to any make logic.
Maybe, I don't use fancy GUI IDEs. My IDE is Unix and have never
found rules that cannot be matched with make and other simple Unix
tools.
urs
--
GUIs normally make it simple to accomplish simple actions and
impossible to accomplish complex actions.
-- Doug Gwyn (22/Jun/91 in comp.unix.wizards)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
