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

[Karr, David]

> At 07:03 PM 7/23/2003, Karr, David wrote:
>=20
> >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.
>=20
>=20
> Since this question comes up frequently,
> I have created a FAQ entry for it:=20
> =
http://www . cmake . org/cgi-bin/cmakefaq . cgi?req=3Dshow&file=3Dfaq05 . 005 . htp=

>=20
> 5.5. Why does CMake use full paths, or can I copy my build tree?

The FAQ entry is useful.  My question, however, is really one
that is not even asked in the FAQ.

I don't want to move or copy a build tree.  My concern is that
my developers frequently do copy source trees.

Upon copying a source tree, which happens to be a build tree=20
as well (because this project is built in place), the developer
will have made out-of-place copies of the .dsw and .dsp files,
because Windows makes it too inconvenient to copy "everything=20
except *.dsw".  It's a virtual certainty that sooner or later=20
someone will forget to delete or overwrite these files, and
will open the .dsw file and start working.  At that point all
hell breaks loose.

These issues arise only because I'm trying to retrofit a large
established project to CMake.  If I were using CMake on a new=20
project, I wouldn't have any problem with the use of full paths
(see below).


> Currently (cmake 1.6.X, and cmake 1.7.x=20
> ) do not support fixing a moved binary tree. This feature may=20
> be added before 1.8. If that feature were added, it would=20
> still require cmake to be re-run by hand each time a build=20
> tree is moved.=20

I didn't realize this feature was not currently supported.  That
also could create a serious problem.

> CMake is of course open source and you can "hack" it if you want. =20
> However, beware there are issues with using relative paths for part
> of the system.   If you just did the source files as you suggest, the
> binary files if executable output was set would still end up=20
> in the old build tree.

Actually, I didn't say I'd do ONLY the source files. =20
Our output paths too are all relative paths in our=20
non-CMake-generated project files.  I would have expected
to keep doing this.

(If your error were to happen, however, I'd regard it as less
disastrous than an overwritten source file, which represents
coding effort lost forever.  At least in this case, once you
recognized the error you could restore all directories quickly
to their correct contents--essentially, clean and rebuild.)

On the other hand I would not want to use relative paths in
order to find third-party libaries my code needs to import.
I've seen it done, but it's a very bad tradeoff and one of the
attractions of CMake is it makes all perceived need for such
nonsense just go away.


> Also, some of the above problems may happen.

Yes, I don't see any way to eliminate all risk in copying
a build tree.  It's only a question of what will break and
how bad the consequences are.

If I can set up a safe environment with a "standard" CMake,
I'd much rather do that than hack anything; I don't really
want to add extra tool development to the project schedule.
If it's not an option to explicitly specify in CMakeLists.txt
a relative path that is to be used with one or more sources
or targets, I see several alternatives, and would probably=20
end up doing one of the following:

1. Use separate build and source trees.  This would be my
preference for a new project in any case; it solves a lot of
problems, not just the path question.  It might be difficult=20
to put in place on a project that has a couple of years=20
of history already.  On the other hand, unlike the ideas
below, this procedure is self-enforcing.

2. Put in place a "no copy" rule: tell the developers that
if they need a new source tree, they must check out a fresh
one from the source code repository.  A side effect is that
if they develop code on one machine, they have to check it
in before they can test it on any other machine.

3. Write a script that purges the generated files from a
source/build tree, and make a rule that developers must
run that script before copying any source.

4. Allow copying, but only if (a) you are copying from one=20
host to a different host and (b) if the path you're copying
from also exists on the destination host, you copy the files
to that same path.  (Opening and/or building the source could
still break then, but this would be fully remedied by
running CMake again.)


-- David A. Karr (karr at acm . org)