[Cmake] Set a variable to a list of filenames that match a
pattern
Andy Cedilnik
andy . cedilnik at kitware . com
23 Jul 2003 13:42:48 -0400
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?