[cmake-developers] Safe source list GLOBs
Matthew Woehlke
matthew.woehlke at kitware.com
Fri May 24 11:21:57 EDT 2013
On 2013-05-19 19:47, Wojciech Knapik wrote:
> I you ever put "junk files" with, say, a .cpp extension in a source tree
> of a C++ project, you're the only one to blame.
This is not unusual at all. I'm often in the situation where I have
source files for classes that are works in progress, tangent thoughts
that I don't want to get rid of, or for whatever other reason are still
floating around (generally not committed). That doesn't mean I want to
build them.
Worse, I may have source files that should only be built on certain
platforms or if certain features are enabled. There may be reasons why
it is not desirable to have these in a different location.
Another not-uncommon scenario is leftover generated source files in the
build directory, e.g. because I switched to a branch that doesn't have a
class for which files were previously generated. Possibly these would
*always* be explicitly listed, but if not, I would have to remove my
build directory on switching branches to avoid build errors.
With explicit lists, none of these cases pose a problem.
> For how many people learning CMake is it predictable, or intuitive, that
> GLOBs will only be expanded when generating the build system ?
GLOB is just one of many things that will surprise you when working with
CMake if you don't understand the difference between the configure and
build passes.
In order for glob-based file lists to ever fully work would require
either (a) re-evaluating the globs at every build in order to determine
if CMake needs to re-run, or (b) always re-running CMake.
(b) is just plain unacceptable for projects that take a non-trivial time
to configure (e.g. VTK, although most non-trivial projects take at least
several seconds).
(a) is probably not possible in a portable manner without doing it from
within CMake, and even still will likely increase no-op build time by a
non-trivial amount, especially for e.g. Ninja which otherwise does
extremely fast no-op builds.
> Wait, are you saying that expanding GLOBs is so slow, that it would have
> a noticeable impact on your build time ?
Compared to a ninja no-op build? I don't have numbers, but I wouldn't be
surprised if it's less unnoticeable than you think.
--
Matthew
More information about the cmake-developers
mailing list