[cmake-developers] Safe source list GLOBs

[Wojciech Knapik]

On Mon, May 20, 2013 at 01:47:12AM +0200, Wojciech Knapik wrote:

> On Wed, May 15, 2013 at 09:50:34AM -0400, Bill Hoffman wrote:
> 
> > On 5/15/2013 4:48 AM, Wojciech Knapik wrote:
> >
> > > On Tue, May 14, 2013 at 03:55:37PM -0400, Bill Hoffman wrote:
> > >
> > >> Globs simply do not work well for source files.
> > >
> > > GLOBs work great for source files. Just not with CMake currently ;]
> > 
> > No it does not. It is sloppy IMO. It will pick up junk files.
> 
> http://en.wikipedia.org/wiki/Garbage_in,_garbage_out
> 
> 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.
> 
> > It can create a whole host of unpredictable things to happy.
> 
> For how many people learning CMake is it predictable, or intuitive, that
> GLOBs will only be expanded when generating the build system ?
> 
> That's a violation of
> http://en.wikipedia.org/wiki/Principle_of_least_astonishment
> 
> > Let's say a file is accidentally deleted, or added to a directory, or
> > gets packaged incorrectly. 
> 
> Sure, mistakes happen, but you optimize your code for the most common
> use cases, not for the possibility of someone doing something wrong.
> 
> It seems to me like a case of throwing out the baby with the bath water.
> 
> > It moves the error to link or compile time instead of configure time.
> 
> If you add a file to a directory, but forget to propagate that
> information to your CMakeList, your code will likely still compile and
> get packaged into a library for instance.
> 
> But again, you're opting to optimize CMake for the relatively rare cases
> at the expense of the most common case. And quite an expense it is...
> 
> Explicit lists violate DRY
> http://en.wikipedia.org/wiki/Don't_repeat_yourself
> 
> There are very few cases where introducing redundancy is justified. And
> even fewer where it's ok to shift the burden of maintaining sync to your
> user, via a manual process no less.
> 
> Removing explicit lists in favour of GLOBs can reduce the size of your
> CMakeLists by an order of magnitude. That's something you want.
> 
> > Removing a file from the build requires deleting the file from the
> > disk instead of just removing it from a list.
> 
> Personally, when I don't need a file anymore, I go to `rm', not `vim'.
> 
> Every time I hear a developer say, that he left a file in version
> control, that's no longer being built, because "we might still need it
> one day" my eyes fill with blood and violence ensues.
> 
> You either need the file, or you don't. Have some discipline for crying
> out loud, nothing is lost in a VCS, that's the whole point.
> 
> > Also, it requires the build system to query the whole directory tree
> > before each build so it is slow by nature.
> 
> Wait, are you saying that expanding GLOBs is so slow, that it would have
> a noticeable impact on your build time ?
> 
> Unless you're building on NFS, or a floppy disk, the performance penalty
> is for all intents and purposes zero.
> 
> > I don't see what the big deal is.
> 
> Perhaps you would, the first time you ran into a library with a
> triple-digit number of objects and 50-character source file names in
> Hungarian notation.
> 
> > > Agreed. The problem remains though.
> >
> > I don't see it as a problem that can or even should be fixed.
> 
> Google it - quite a few CMake users do. 

Can I expect a reply to that ? It took some effort to write all this
down and I list valid arguments. 

WK