[CMake] Problem with generated source and header files
loose at astron.nl
Wed Jul 1 03:33:35 EDT 2009
The problem with globbing is that CMake has no way to determine that new
source (or header) files were added to a directory, other than ALWAYS
running when someone types 'make' (or the VS equivalent). This is not
really desirable behaviour, because oftentimes no new files will have
been added. And therefore, that's not how CMake behaves.
So, in general, when using globbing, YOU are responsible for rerunning
CMake whenever you've added a source file. Otherwise you run the risk of
the new file not being compiled. Furthermore, you might accidentally
compile sources that were just lying around in your directory as test
code. Deletion of sources can also cause interesting effects if you
create a library, because the object will remain in that library until
you (manually) remove and recreate the library.
I hope my examples convinced you enough that globbing is (in general) a
On Tue, 2009-06-30 at 11:56 +0200, Jörg Förstner wrote:
> Hi Marcel,
> > Is there a fixed, predictable relation between the input
> > file(s) to the
> > generator and the output file(s) that are generated; like
> > with Bison or
> > Flex?
> The output files' names and contents are derived from a MetaModel. New objects in the MetaModel result in new files' names and contents.
> > If that's the case you can construct the list of files to be generated
> > from the list of input files to the generator.
> I can let the generator output a list of the generated files, see example below. But the list is created, after CMake would need it. It seems a kind of a chicken-or-egg problem.
> SET( AUTO_CPP_FILES
> (while <name1>..<name3> can be anything, depending on the model and not predictable)
> > If the list of input
> > files is not known a priori, you might use globbing (assuming
> > it will be
> > known once CMake is being run), but avoid that if possible, because it
> > hinders CMake's dependency analysis.
> In several threads I have read about file globbing, that it would be a bad idea. What's the cause exactly, does CMake have a problem with the dependencies then?
More information about the CMake