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

[Karr, David]

> There are two issues here.

Indeed.  Now that you have pointed them out, I do think
they need to be treated separately.  Actually there are
at least three issues.

> 1. The use of GLOB to specify source files, although=20
> available in CMake, it is not really a best practice.

I don't disagree.  I can always write some one-use
scripts to generate my initial set of CMakeLists.txt files.
What I was trying to do mainly was to sugar-coat the use of
CMake for other developers to get them on my side when I=20
explain to management why I want to add another "third-party"
tool to our environment.

Even with native Visual Studio, which we are using now, we
have to go through a specific set of not-so-obvious steps to
correctly add a source file to the project, and it doesn't=20
seem particularly harder to do in CMake.  Globbing the files
would just be a convenience, useful perhaps for a quick start
on a project.  Maybe a CMakeMake tool (you run it in a
directory, and it tries to guess all the CMakeList.txt files
you need) would be a better approach. :-)  This is not a
big problem.

> Also, this avoids files getting mistakenly
> added to a build because someone created a .cxx file in a=20
> directory that was being globbed.

I don't find this a major concern on the particular project
I had in mind; our environment is such that if the file did not
belong in the build, it should never have been in that directory
in the first place.  But other environments are different and
this is a good reason why globbing is not always a valid approach.


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

The part about "CMake should be re-run" is fine.  I really would=20
prefer my developers never to open a workspace that was copied=20
from another directory, but rather rely on the copied=20
CMakeLists.txt and generate the workspace anew.  The parts about
"should never be copied" and "the paths are all full" raise a
third issue, however, which is:

3. The question is, what actually happens if a Windows user copies=20
an entire snapshot of the project, generated files and all, to a=20
new location, and forgets to re-run CMake immediately?

The story you are about to read is true.  Only the names have been=20
changed to protect the innocent.

I had a directory /user/karr/project/try_cmake/foo where CMake had=20
generated a workspace file foo.dsw.  Interestingly, the filenames
in foo.dsw were specified by relative paths, not full paths.
I copied the entire directory tree to /user/karr/temp/foo. =20
Then I opened the workspace /user/karr/temp/foo/foo.dsw in Visual=20
Studio, navigated to the "bar" project, and opened the file
xyzzy.cpp.  I added some text to the top of the file and saved it.

Naively, one would expect that since I had opened the workspace
/user/karr/temp/foo/foo.dsw, my inserted text would show up in the
file /user/karr/temp/foo/bar/xyzzy.cpp.  It didn't.  Instead, it
showed up in /user/karr/project/try_cmake/foo/bar/xyzzy.cpp, that
is, in the wrong directory.

By the way, because foo.dsw was written with relative paths,=20
I was accessing the copy of bar.dsp in the right directory
(which I could confirm by examining its "Properties" in
Visual Studio).  The problem was in bar.dsp, which was still
pointing to files in the old directory.

This is an extremely evil outcome IMHO. =20

Obviously, I should tell developers, "Don't do this," but=20
being human they may forget once in a while and this can=20
really ruin someone's day--either for the forgetful person=20
or for a completely innocent bystander whose files were copied.


This is not a question of whether the file is portable or=20
whether you will be able to rebuild your project without running=20
CMake first.  It's a question of having a pitfall that's not
obvious to the casual user that can cause some very serious
accidental damage to their work or the work of others.

This gets back to my earlier question.  When Visual Studio=20
writes the source groups in a .dsp file (e.g. when you use the=20
"Add Files to Folder" command from the popup menu), it uses=20
relative  paths in every case as far as I can tell.  I have
less experience with Visual Studio than with makefiles, but
in two years of heavy usage I've never seen any adverse effects
of these relative paths.  Why must CMake do it differently? =20
It seems to entail a big risk for no benefit that I can see.

In the absence of a good explanation, I would probably hack
this "feature" out of CMake before I let any of my developers
use it.

-- David