[cmake-developers] Safe source list GLOBs

[David Cole]

-----Original Message-----
From: Alexander Neundorf <neundorf at kde.org>
To: cmake-developers <cmake-developers at cmake.org>
Sent: Thu, May 23, 2013 12:55 pm
Subject: Re: [cmake-developers] Safe source list GLOBs


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

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




The problem is Wojciech is saying one thing as a CMake newbie, and the 
CMake devs are hearing it through the filter they've learned.

The problem, as I hear it, is that a project new to CMake wants to make 
CMakeLists files as quickly as possible and get something building. At 
first glance, using glob, when you have more than just a handful of 
source files, seems like an attractive option from a new-to-CMake 
dude's perspective.

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.

Perhaps the solution to this problem is to provide some easy ways of 
generating CMakeLists files for projects that are moving to CMake from 
some other build system. It's a real-world problem that seems mostly to 
be solved by brute force typing on a per-project basis. I know a couple 
people out there have done some scripts, but there's probably room for 
a tool or script that could just analyze a directory structure of 
source files and come up with a "suggested set of CMakeLists.txt files."

Either system of specifying build files (explicit lists, or implicit 
"all files existing on disk that match this file extension") can work. 
It's merely a matter of what your developers are used to, and what 
steps they take to ensure consistent builds. With either system, there 
are ways to make mistakes, and get build problems.

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. But don't 
forget: people new to CMake don't share that view yet, and it will take 
them some time using CMake before they understand why we cling so 
strongly to that opinion here.


David C.