[CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)

[David.Karr at L-3COM.COM]

>>> find . -name "*.c" > source_files.txt
>>> edit source_files.txt and put that list of files exiplicitly into a
>>> CMakeLists.txt file.
>>>
>>> file(GLOB is a bad way to get source lists for CMake.   CMake has 
>>> no way of knowing when new files have been put in the directory.
>>
>> But unless I am missing a fundamental feature somewhere, GLOB still
>> seems to be the better alternative. While it may not intrinsically
>> know when new files have appeared on the filesystem, the programmer
>> can simply re-run the CMake command to get an updated project with
>> the newly added source files without editing the CMakeLists.txt
>> file directly.
>
>Yes but when he add a source file, he won't necessarily remember he
>MUST rerun CMake manually [...]
>
>Whereas with hard-written sources files in CMakeLists.txt, the user
>will get accustomed to "simple" CMakeList.txt editing [...]
>
>[...]
>
>It usually looks like a better alternative (but I may be wrong) when
>you are in the process of converting several project to CMake and you
>end-up writing a lot of boring CMakeLists.txt in the startup process
>:=)

Actually, when I was last faced with this task I decided the easier
alternative for me was to cut and paste a lot of boring directory
listings into my CMakeLists.txt files.  (This was in a much earlier
version of CMake, and IIRC there was some problem with file globbing
back then that was fixed soon afterward.)

The reason for my choice at that time was user acceptance.  I had a
brief window of opportunity to introduce a new build system based on
CMake, which did not give me time to train all the developers in CMake
before deploying it.  One of the first objections I received was that
it was "much harder" to add, remove, or rename source files in CMake
than via the Visual Studio interface.  So I made it a "pushbutton"
process: the developer just had to run a script named something like
MakeWorkspace.bat.

Besides the project developers themselves, I also had users who needed
to be able just to build the project without doing any development on
it.  I actually got in trouble with those users on account of the one
directory where I had listed the source files individually instead
of "globbing" them.  The problem was solved when we "globbed" that
directory too.

I've had second thoughts about all this, for example the other day
when someone forgot to tell a developer newly introduced to this
project that he needed to run the script after adding source
files--that is, we forgot until he came to me asking about his link
errors.  On the other hand, it takes very little time for people to
develop new habits that tell them when to re-run the script.  I'm
probably going to change some things about the build procedure sooner
or later, but I don't know if or when this will be one of them.

The conclusion for me is that when I write a CMakeLists.txt file for a
personal project, I never "glob" the files; but the build design of a
long-running project needs to account for who is working on it and
what procedures will work best for them.  That may imply listing the
files explicitly, but it could conceivably imply "globbing" them.

David Karr