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