[cmake-developers] Safe source list GLOBs

[Matthew Woehlke]

On 2013-05-28 19:50, Wojciech Knapik wrote:
> Files don't just happen to be lying around in directories. You have to
> create them in a specific path, with a specific name. Even if the act of
> creation was performed by another developer, on another machine, that
> information is written to disk in the course of a VCS checkout.

IOW, you are claiming that *the VCS* is authoritative. (Personally I 
would claim, at least as things stand now, that CMakeLists.txt is 
authoritative, and any discrepancies with the files on disk represent 
mistakes.)

...which (see more below) is actually an interesting idea.

> The contents of the directory rules. If you remove a file from it,
> there's nothing you can do in a CMakeList to help it. If you add a file
> to it and you use GLOBs, there's nothing that you need to do in a
> CMakeList for it to be built. (*)

In practice, developers *are* going to create 'scratch' files in source 
directories. Or forget to add new files when committing.

In the latter case, at least having CMakeLists.txt specifically ask for 
the file will make it much more immediately obvious when this mistake 
happens.

If there were a way to ask *the VCS* for the file list, I could see that 
being useful; it would avoid the problem with 'scratch' files, and would 
also help prevent forgetting to add files (since the developer would get 
broken functionality at least until staging the addition). But of course 
this would need to degrade gracefully when dealing with release 
tarballs. (Ideally the release tarball would use an explicit list.)

Having an explicit list also helps guard against accidental deletion by 
requiring an explicit change when a file should no longer be part of the 
build. Using the VCS's expected file list could also serve this purpose, 
but this would be another argument for at least source tarballs to use 
explicit lists.

> What's the point of GLOBs anyway if you only reliably expand them once ?

I have often thought that GLOB is more dangerous than useful :-). 
(Especially as I can't think of having ever used it.)

> Who wants a snapshot of the past state of a location on disk in a build
> system ?

They're potentially useful for operations performed at configure time, 
at which point they are current. If you're persisting them into the 
build rules without some way of checking if they are still correct, then 
you're doing it wrong :-).

> On Thu, May 23, 2013 at 01:13:12PM -0400, David Cole wrote:
>> People who are not used to CMake (perhaps) don't realize that when you
>> edit a CMakeLists file, or any of its inputs, the expectation is that
>> simply typing "make" will do a build, re-running cmake as needed, and
>> only when needed.
>
> What's so special about CMake, that it's ok for you guys to break that
> principle, but not ok for others ?

Really? Autotools is the same way (except I think they just break when 
the autotools chain needs to be re-run, rather than trying to make it 
happen automagically).

To some extent, anything with a configure script is the same way...

Does this really only 'bother' people using CMake? (And if so, why? 
Honest question...) Or do other build systems have the same problem?

>> When somebody asks about "GLOB," we CMake devs have a learned "GLOBs
>> are evil, don't use them" response that we make out of habit.
>
> If you take a step back, forget about the CMake internals for a moment
> and read that sentence again - does it sound ok to you ?

Er... mostly. Say better, GLOB is not something you should use unless 
you really know what you are doing with it, why you need it, and how to 
use it correctly.

-- 
Matthew