[cmake-developers] Safe source list GLOBs

Alexander Neundorf neundorf at kde.org
Thu May 23 12:57:34 EDT 2013


On Thursday 23 May 2013, Wojciech Knapik wrote:
> 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...

I also don't agree that it is quite an expense.
It never bothered me nor any of my colleagues. They all do just fine and never 
complained about that. In an IDE you have to add a file sonmewhere to the 
project, in cmake you have to add it to the CMakeLists.txt.

> > Explicit lists violate DRY
> > http://en.wikipedia.org/wiki/Don't_repeat_yourself

No, this doesn't apply :-)
By having some files lying around in a directory I did not state anything, so 
I do not repeat myself in the CMakeLists.txt ;-)

The contents of the CMakeLists.txt are the reference.


> > 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.

I do not want it.
I like if the CMakeLists.txt can tell me explicitely which files are used for 
which targets, and I don't have to do the glob matching in my head when 
reading it.

> > > 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.

Still, I don't see a problem.
What is the problem ?

Alex



More information about the cmake-developers mailing list