[CMake] Generating include files

Craig Scott craig.scott at crascit.com
Sat May 20 05:25:05 EDT 2017


On Sat, May 20, 2017 at 7:16 PM, Urs Thuermann <urs at isnogud.escape.de>
wrote:

> Craig Scott <craig.scott at crascit.com> writes:
>
> > Another choice is to set the OBJECT_DEPENDS property on foo.c, even
> though
> > the documentation for that source property says it shouldn't be needed.
> The
> > OBJECT_DEPENDS property sets up a dependency between files rather than
> > targets and can be used like this:
> >
> >     cmake_minimum_required(VERSION 3.0)
> >     project(simple)
> >
> >     add_custom_command(
> >         OUTPUT           ${CMAKE_BINARY_DIR}/tab.h
> >         COMMAND "mktab > ${CMAKE_BINARY_DIR}/tab.h"
> >     )
> >
> >     include_directories(${CMAKE_BINARY_DIR})
> >
> >     add_executable(foo foo.c)
> >     set_source_files_properties(foo.c PROPERTIES OBJECT_DEPENDS
> > ${CMAKE_BINARY_DIR}/tab.h)
>
> 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.  But it seems that cmake doesn't want the developer to see or
> talk about object files.  It hides them somewhere in subdirs (with
> unpredictable names (sometimes foo.o, sometimes a silly name like
> foo.c.o, sometimes both), so after make foo.o I don't know which one
> is current), gives error messages if I use them in CMakeLists.txt...
>

OBJECT_DEPENDS expresses exactly that. It says "object files built from
this source file depend on these things". That's why it's called
OBJECT_DEPENDS instead of just DEPENDS like other dependency-related
keywords. But I do agree with your general feeling that this is more
complicated than it should ideally be. Intuitively, it feels like something
CMake should be able to work out for itself, but perhaps there's some
limitation in the implementation of one or more of the generator types
which makes it hard. I'll leave that for those with a more intimate
knowledge of CMake's internals to comment on.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170520/a4e95bb4/attachment.html>


More information about the CMake mailing list