[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