[cmake-developers] Safe source list GLOBs

[Wojciech Knapik]

On Thu, May 30, 2013 at 08:27:28AM +0200, Michael Wild wrote:

> Also, very astonishing to me is the fact that after apparently finding
> file(GLOB) in the documentation, you clearly didn't read the whole
> paragraph. It's right there:
> 
> >> We do not recommend using  GLOB  to collect  a list of source files
> >> from your source tree.  If no CMakeLists.txt file changes when a
> >> source is added or removed then the generated build system cannot
> >> know when to ask CMake to regenerate.
> 
> As you are so fond of clear violations: You failed to RTFM...
> (http://en.wikipedia.org/wiki/Rtfm)

Have you ever assumed, when crossing a street you know very well, that
cars will only come from one side and neglected to look in the other
direction ?

I needed a function to glob, I read the signature and went on to use it.

I did notice that in the documentation later.

> Besides, you seem to be very sure that CMake is the *only* tool that
> prefers explicit source file listing. 

Nope.

> Have you ever used any of the popular IDE's? Visual Studio? Xcode?
> Eclipse? They all create explicit list of files in their projects.

An IDE is a different class of tool, that builds on top of tools such as
CMake. Apples and oranges.

> What are the (not so serious) pros and cons of GLOB, even if it worked
> the way you think it should?
> 
> Pro:
> * laziness

You say it, like it's a bad thing.

> Con:
> * laziness
> * extremely error prone:
>   - picks up scratch files
>   - works for you but breaks for others because you forgot to commit a
>     file
>   - breaks for you because the other dude forgot to commit his file
> * makes it unnecessarily difficult to exclude files from the build
>   - temporarily: for testing (you'd need to move the file away and then
>     remember to move it back; error prone again)
>   - permanently: dependent on the platform, configuration, enabled
>     capabilities etc. And using #ifdef's for this is bad because you
>     still invoke the compiler and waste time to just compile an "empty"
>     file.
> * when reading the build system code, you have to switch context in
>   order to determine the files included in the build.

We've been through all these points earlier in this thread.

> On the other hand, initially creating and then maintaining an explicit
> list of files is easy. Initially I usually create the list of files like
> this using vim:
> 
> :r !cd $(dirname %); ls **/*.{c,cpp}; ls **/*.{h,hpp}

It's not about the difficulty of creating a file list.

WK