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

[Andy Cedilnik]

Hi David,

Well, here lies the problem. You cannot move (or copy) the build
location. All paths in DSP, DSW, Makefile... are absolute.

Even if you say:

ADD_EXECUTABLE(foo foo.cxx)

the actual path to foo.cxx is absolute. This solves a lot of problems.
Trust me.

			Andy

On Wed, 2003-07-23 at 13:35, Karr, David wrote:
> (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?