[Cmake] Set a variable to a list of filenames that match a pattern

[Bill Hoffman]

There are two issues here.

1. The use of GLOB to specify source files, although available in CMake,
it is not really a best practice.  It leads to problems, because CMake has
no way of knowing when it needs to be re-run, or new source files have been added.
The user must know when to re-run CMake.   It is much safer to explicitly list
all the files used by a project in the CMakeLists.txt file.   This way the only
way to add new files is to edit the CMakeLists.txt file, and CMake has rules
that re-run CMake when that file changes.   Also, this avoids files getting mistakenly
added to a build because someone created a .cxx file in a directory that was
being globbed.  

2. The binary trees for CMake generated projects should never be copied and
are not portable.  CMake should be re-run to generate a new tree each time
one is required.  The paths are all full in the generated Makefiles/dsp/vcproj files.

-Bill


At 01:35 PM 7/23/2003, Karr, David wrote:
>> FILE(GLOB var "${CMAKE_CURRENT_SOURCE_DIR}/*.cxx") 
>> 
>> and 
>> 
>> FILE(GLOB var "*.cxx") 
>> 
>> is the same.
>> 
>> I just do not think it is a good think to refer to things relatively.
>> So, you better use full path to things.
>> 
>> Why would you need relative paths anyway?
>> 
>>                               Andy
>
>
>Under the wrong circumstances, using the full path to something
>could be dangerous.
>
>Consider the following files on a Windows host:
>
>  C:/user/alice/project/foo/CMakeLists.txt
>  C:/user/alice/project/foo/foo.dsw
>  C:/user/alice/project/foo/bar/CMakeLists.txt
>  C:/user/alice/project/foo/bar/bar.dsp
>  C:/user/alice/project/foo/bar/xyzzy.cpp
>  C:/user/bob/project/
>  C:/thirdparty/lib/blah.lib
>
>(Yes, the slashes are wrong way around.)  The directory
>C:/user/alice/project/foo is a snapshot of the "foo"
>project that Alice extracted from the source repository.
>The files foo.dsw and bar.dsp were generated when Alice 
>ran cmake in C:/user/alice/project/foo, and because 
>bar/CMakeLists.txt uses FILE(GLOB var regex) feature to 
>find the files to put in the source group 
>"Weird Files", bar.dsp specifies all files in that source
> group by full paths rather than the relative paths.
>
>Now Bob decides he wants to try adding some code to the
>"foo" project based on other code Alice just added.  To
>avoid interfering with Alice while she does her work, Bob
>makes his own private copy of Alice's snapshot, that is,
>he recursively copies C:/user/alice/project/foo and all 
>its subdirectories onto C:/user/bob/project/foo.
>
>But it doesn't occur to Bob that he needs to run CMake
>again, because C:/user/bob/project/foo/foo.dsw already 
>exists.  So Bob opens C:/user/bob/project/foo/foo.dsw.
>Then within Visual Studio he opens the "bar" project,
>and within that he opens the source group "Weird Files".
>He sees the file he wants to edit, xyzzy.cpp.  He
>proceeds to open xyzzy.cpp, edit it, and save it.  Now
>what Bob thinks he's just done is to make a change to
>his copy of the file, C:/user/bob/project/foo/bar/xyzzy.cpp, 
>but what he's actually done is to edit Alice's copy of the 
>file, C:/user/alice/project/foo/bar/xyzzy.cpp, because
>bar.dsp specified that file using that full path.  Evil!
>
>If bar.dsp had specified the path to xyzzy.cpp in the group 
>"Weird Files" as imply "xyzzy.cpp" or "./xyzzy.cpp", then 
>the result of Bob's actions would have been to do exactly 
>what Bob wanted, namely edit his own copy of the file.
>
>I haven't run into this exact problem yet, because at this
>point I'm still trying to adapt my biggest project to CMake
>(and/or the other way around) and no other developer even
>knows where my generated files are.  But I *have* had past
>experiences in which, due to some unfortunate interaction 
>between ClearCase and Visual Studio, I've ended up with 
>.dsp files in which files were specified by full paths.  
>This caused big headaches (among other problems, IIRC 
>I did end up editing the wrong copy of a file at least 
>once), and this is one of the things I was hoping CMake 
>would solve for me.
>
>In fact, let me turn the question around.  If you let 
>Visual Studio add all the .cpp files in a directory to a 
>project in the same directory, it will insert the filenames 
>in the .dsp file without any path at all.  Why would you 
>want the full paths?
>
>That's not to say full paths are always evil.  For example,
>if bar.dll in the "foo" project needs to be linked with
>C:/thirdparty/lib/blah.lib, then it makes sense always
>to specify that file by its full path.  Otherwise you end
>up with relative paths full of ../.., etc., and everything
>breaks as soon as anyone makes the slightest change to 
>which files are kept where, or even tries to compile the
>project on a different disk partition than where the
>library is kept.
>
>But have I explained why *sometimes* I want to use 
>relative paths?
>
>-- David
>_______________________________________________
>Cmake mailing list
>Cmake at www . cmake . org
>http://www . cmake . org/mailman/listinfo/cmake