On Wed, May 29, 2013 at 04:55:33PM -0400, Matthew Woehlke wrote: > On 2013-05-28 19:50, Wojciech Knapik wrote: > > > 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. > > IOW, you are claiming that *the VCS* is authoritative. (Personally I > would claim, at least as things stand now, that CMakeLists.txt is > authoritative, and any discrepancies with the files on disk represent > mistakes.)
The VCS client only writes files to a filesystem. What's on disk is your underlying reality. The file listing in a CMakeList represents either a) A 1-to-1 copy of what's on the filesystem, or b) A modified version of that If you choose to go with option a), an explicit file listing is redundant, with all the consequences. If you choose option b), an explicit file listing may be a better fit. What I'm arguing, is that option a) is a legitimate choice and should be possible without the redundant file list in a CMakeList. > > 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 practice, developers *are* going to create 'scratch' files in source > directories. Like I wrote before - dot files will not be picked up by even the most general globs, making it perfectly safe to combine globs and scratch files. Just call your scratch file .foo.cpp instead of foo.cpp and all will be fine. > Or forget to add new files when committing. > In the latter case, at least having CMakeLists.txt specifically ask for > the file will make it much more immediately obvious when this mistake > happens. Should CMake be optimized for building proper commits, or broken ones ? As of now, even if I never make mistakes while committing my code, I can't use all files matching a glob to build a target, without introducing redundancy to my build system. That, to me, seems like optimizing for a corner case at the cost of an arguably common one. > If there were a way to ask *the VCS* for the file list, I could see that > being useful; it would avoid the problem with 'scratch' files, and would > also help prevent forgetting to add files (since the developer would get > broken functionality at least until staging the addition). But of course > this would need to degrade gracefully when dealing with release > tarballs. (Ideally the release tarball would use an explicit list.) Magic like this is fine in an IDE, not in a build system. A build system should be VCS-agnostic IMO. Whether you do `svn co', or `svn export', or just get a tarball from a colleague, the build system should work the same. When your project switches to a different VCS, that should not require changing the build system in any way. > Having an explicit list also helps guard against accidental deletion by > requiring an explicit change when a file should no longer be part of the > build. Using the VCS's expected file list could also serve this purpose, > but this would be another argument for at least source tarballs to use > explicit lists. Yes, an explicit list would make such a problem visible more quickly. But again - that's an optimization geared towards broken commits, at the cost of a legitimate use case, where no mistakes were made while committing. > > What's the point of GLOBs anyway if you only reliably expand them once ? > > I have often thought that GLOB is more dangerous than useful :-). > (Especially as I can't think of having ever used it.) To each their own. Just don't set(CMAKE_DYNAMIC_GLOBS TRUE) ;-) > > Who wants a snapshot of the past state of a location on disk in a build > > system ? > > They're potentially useful for operations performed at configure time, > at which point they are current. If you're persisting them into the > build rules without some way of checking if they are still correct, then > you're doing it wrong :-). That's the way it is now if you use globs with no mechanism to re-expand them when necessary. That's what I'd like to see changed. > >> 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. > > > > What's so special about CMake, that it's ok for you guys to break that > > principle, but not ok for others ? > > Really? Autotools is the same way (except I think they just break when > the autotools chain needs to be re-run, rather than trying to make it > happen automagically). It's an obvious comparison (with autotools), true, but a bad point of reference IMO ;] > To some extent, anything with a configure script is the same way... > > Does this really only 'bother' people using CMake? (And if so, why? > Honest question...) Or do other build systems have the same problem? I don't know. The only build tool I'm *really* familiar with is gmake/emake and I would guess that's the case for many people deciding to use CMake for the first time. In makefiles, you don't have a configure phase, so wildcards don't pose a similar problem. Such a person then feels that a feature has been taken away from them, whether rightly so, or not ;] Other tools with a configure phase have the same problem, but I guess people's expectations towards CMake are higher, since the project is relatively new and in active development. > >> 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 ? > > Er... mostly. Say better, GLOB is not something you should use unless > you really know what you are doing with it, why you need it, and how to > use it correctly. Well, I know what I'm doing and why I need it, but I still have a problem :/ I know that build tools with a configure phase are different. But CMake does provide a globbing facility and it does re-run the configure phase when necessary (in some cases, like CMakeList updates) - this suggests that globs could be made to work properly, despite the two-phase build process. I would love to be the one to give CMake users a way to safely use globs for file lists, but I simply don't know (and don't really care to learn) C++, so all I can do is suggest to you guys, that it's an idea at least worth revisiting. 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
