On Thu, May 23, 2013 at 01:13:12PM -0400, David Cole wrote: > > > 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 ;-)
Quoting myself from the previous email: Files don't just happen to be lying around in directories. You have to create them in a specific path, with a specific name. Even if the act of creation was performed by another developer, on another machine, that information is written to disk in the course of a VCS checkout. So, yeah, you're repeating information that's already there. > The contents of the CMakeLists.txt are the reference. The contents of the directory rules. If you remove a file from it, there's nothing you can do in a CMakeList to help it. If you add a file to it and you use GLOBs, there's nothing that you need to do in a CMakeList for it to be built. (*) In other words - I could create, modify, rename and remove source files by using the file system alone and have everything work. I could not do the same in CMakeLists alone. That's the hallmark of an authoritative source of information, one that's, by definition, safer to rely on. > 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. Sure. Many of your new users will be coming from the make world, where using wildcards is not problematic the way it is in CMake. I guess that just makes it that much more of a surprise for these users to learn, that GLOBs don't work quite the way they expected. What's the point of GLOBs anyway if you only reliably expand them once ? Who wants a snapshot of the past state of a location on disk in a build system ? > 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. http://en.wikipedia.org/wiki/Principle_of_least_astonishment It's a great UI design principle. Perhaps the most obvious and most significant one. What's so special about CMake, that it's ok for you guys to break that principle, but not ok for others ? Is there a reason, or is it just a side-effect of the implementation with some rationalization on top ? > 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." I can do `echo *.cpp >>CMakeLists.txt', that's not a big problem. And I certainly wouldn't use a special tool just for that. > Either system of specifying build files (explicit lists, or implicit > "all files existing on disk that match this file extension") can work. All the more reason to give users a choice. > 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. If you take a step back, forget about the CMake internals for a moment and read that sentence again - does it sound ok to you ? WK (*) At least if you use my module, or patch CMake to re-expand GLOBs every time you call the build tool. -- 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
