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

[Karr, David]

> FILE(GLOB var "${CMAKE_CURRENT_SOURCE_DIR}/*.cxx")=20
>=20
> and=20
>=20
> FILE(GLOB var "*.cxx")=20
>=20
> is the same.
>=20
> I just do not think it is a good think to refer to things relatively.
> So, you better use full path to things.
>=20
> Why would you need relative paths anyway?
>=20
> 				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=20
ran cmake in C:/user/alice/project/foo, and because=20
bar/CMakeLists.txt uses FILE(GLOB var regex) feature to=20
find the files to put in the source group=20
"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=20
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=20
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,=20
but what he's actually done is to edit Alice's copy of the=20
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=20
"Weird Files" as imply "xyzzy.cpp" or "./xyzzy.cpp", then=20
the result of Bob's actions would have been to do exactly=20
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=20
between ClearCase and Visual Studio, I've ended up with=20
.dsp files in which files were specified by full paths. =20
This caused big headaches (among other problems, IIRC=20
I did end up editing the wrong copy of a file at least=20
once), and this is one of the things I was hoping CMake=20
would solve for me.

In fact, let me turn the question around.  If you let=20
Visual Studio add all the .cpp files in a directory to a=20
project in the same directory, it will insert the filenames=20
in the .dsp file without any path at all.  Why would you=20
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=20
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=20
relative paths?

-- David