[cmake-developers] Safe source list GLOBs

[Wojciech Knapik]

On Wed, May 29, 2013 at 04:59:22PM -0400, Matthew Woehlke wrote:

> On 2013-05-28 21:23, Wojciech Knapik wrote:
>
> > On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote:
> >
> >> 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.
> >
> > I've written quite a bit of CMake code in the past 6 months and so far
> > that's the only thing that really surprised me.
> 
> execute_process? That's at least the main other one I always have to be 
> careful about.

Working with make taught me once and for all, that functions like this
should be avoided whenever possible. A build tool creates files from
files via the means of targets. So if you want to use a tool like this
effectively, you should use targets to achieve your goals, otherwise
unexpected things will happen.

> > I do understand the distinction between calling cmake and make and I
> > understood from the start when variables are evaluated and such, but I
> > just assumed that globs are propagated to the generated build system,
> > because a) why not ? b) what's the point of globs if they aren't ?
> >
> > Imagine my surprise...
> 
> Actually, I find your surprise very surprising. You say you understand 
> that setting and using variables happens at configure time. Well, 
> file(GLOB) populates a variable... so why would you expect those 
> variables to be somehow magically special?

Come to think of it, you're completely right. I can easily imagine a
case where you want to execute some CMake code for, say, every file
globbed. That would require re-running cmake. It just didn't occur to me
until much later.

> > I don't think we need to be concerned about adding a few miliseconds to
> > a no-op build, even if that constitutes a major percentage increase.
> 
> If that was true (and *especially* if the relative cost was 
> non-trivial), ninja probably would not exist. These things add up... a 
> few ms here, a few ms there, and suddenly it takes many seconds to build 
> even a moderately large project set, that could otherwise be built in 
> barely a second (if that). For that matter, even if it made a difference 
> of 'only' 100 ms (say, in something the size of VTK), I would consider 
> that a lot.

s/ms/ns/ if you consider caching.

But like I said:
a) You know where globs are used and you can only re-expand them for
those directories, so if no globs are used, the penalty is next to
nothing
b) The option to re-expand the globs could be turned off by default

> As previously stated, there are really only two ways to do this 
> correctly. One is to just always re-run CMake, which is unacceptable for 
> any project of more than trivial size. The other is to teach CMake to 
> reevaluate its globs and reevaluate if it needs to reconfigure. If this 
> is even *possible* across build managers, it is probably not easy, but 
> if you want to write a patch for that, I feel confident it will be 
> considered.

Like I wrote in the previous email - I'm happy to provide CMake code, or
code in several other languages, but I'm afraid C++ is not one of them.

WK