On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote: > On 2013-05-19 19:47, Wojciech Knapik wrote: > > > 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. > > This is not unusual at all. I'm often in the situation where I have > source files for classes that are works in progress, tangent thoughts > that I don't want to get rid of, or for whatever other reason are still > floating around (generally not committed). That doesn't mean I want to > build them.
Then use "dot files". They're not picked up by globs such as "*.c". > Worse, I may have source files that should only be built on certain > platforms or if certain features are enabled. There may be reasons why > it is not desirable to have these in a different location. Then don't. The use of globs does not imply that you need to take all files with a given extension indiscriminately. You can create more specific globs, or just use list(REMOVE). But there's a dozen ways to deal with conditional compilation. Preprocessor directives, file naming conventions, separate directories, whatever works for you. Globs will not get in the way of using any one of them - if anything, they support the use of http://en.wikipedia.org/wiki/Convention_over_configuration Judging from this thread though, I'd say the technique does not have many fans around here... > Another not-uncommon scenario is leftover generated source files in the > build directory, e.g. because I switched to a branch that doesn't have a > class for which files were previously generated. Possibly these would > *always* be explicitly listed, but if not, I would have to remove my > build directory on switching branches to avoid build errors. There's no point in globbing anything in the binary directory, as you know precisely what files you create in it. > With explicit lists, none of these cases pose a problem. As you can see above, none of these cases pose a problem with globs either. As long as they're properly re-expanded of course. > > For how many people learning CMake is it predictable, or intuitive, that > > GLOBs will only be expanded when generating the build system ? > > GLOB is just one of many things that will surprise you when working with > CMake if you don't understand the difference between the configure and > build passes. I've written quite a bit of CMake code in the past 6 months and so far that's the only thing that really surprised me. I do understand the distinction between calling cmake and make and I understood from the start when variables are evaluated and such, but I just assumed that globs are propagated to the generated build system, because a) why not ? b) what's the point of globs if they aren't ? Imagine my surprise... > In order for glob-based file lists to ever fully work would require > either (a) re-evaluating the globs at every build in order to determine > if CMake needs to re-run, or (b) always re-running CMake. > > (b) is just plain unacceptable for projects that take a non-trivial time > to configure (e.g. VTK, although most non-trivial projects take at least > several seconds). > > (a) is probably not possible in a portable manner without doing it from > within CMake, and even still will likely increase no-op build time by a > non-trivial amount, especially for e.g. Ninja which otherwise does > extremely fast no-op builds. I don't know CMake internals, so I can't comment on the possible implementations, but it is doable. There's no fundamental problem with the idea. > > Wait, are you saying that expanding GLOBs is so slow, that it would have > > a noticeable impact on your build time ? > > Compared to a ninja no-op build? I don't have numbers, but I wouldn't be > surprised if it's less unnoticeable than you think. I don't think we need to be concerned about adding a few miliseconds to a no-op build, even if that constitutes a major percentage increase. To recap: * I don't think everyone should use globs * I don't see a good argument against them, that does not depend on project-specific requirements, or personal preferences * There are arguments for it, that go beyond personal preferences * A feature enabling glob re-expansion on each call to the build tool could be switched off by default 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
