On Wed, May 29, 2013 at 04:59:22PM -0400, Matthew Woehlke wrote: > On 2013-05-28 21:23, Wojciech Knapik wrote: > > > On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote: > > > >> 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. > > execute_process? That's at least the main other one I always have to be > careful about.
Working with make taught me once and for all, that functions like this should be avoided whenever possible. A build tool creates files from files via the means of targets. So if you want to use a tool like this effectively, you should use targets to achieve your goals, otherwise unexpected things will happen. > > 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... > > Actually, I find your surprise very surprising. You say you understand > that setting and using variables happens at configure time. Well, > file(GLOB) populates a variable... so why would you expect those > variables to be somehow magically special? Come to think of it, you're completely right. I can easily imagine a case where you want to execute some CMake code for, say, every file globbed. That would require re-running cmake. It just didn't occur to me until much later. > > 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. > > If that was true (and *especially* if the relative cost was > non-trivial), ninja probably would not exist. These things add up... a > few ms here, a few ms there, and suddenly it takes many seconds to build > even a moderately large project set, that could otherwise be built in > barely a second (if that). For that matter, even if it made a difference > of 'only' 100 ms (say, in something the size of VTK), I would consider > that a lot. s/ms/ns/ if you consider caching. But like I said: a) You know where globs are used and you can only re-expand them for those directories, so if no globs are used, the penalty is next to nothing b) The option to re-expand the globs could be turned off by default > As previously stated, there are really only two ways to do this > correctly. One is to just always re-run CMake, which is unacceptable for > any project of more than trivial size. The other is to teach CMake to > reevaluate its globs and reevaluate if it needs to reconfigure. If this > is even *possible* across build managers, it is probably not easy, but > if you want to write a patch for that, I feel confident it will be > considered. Like I wrote in the previous email - I'm happy to provide CMake code, or code in several other languages, but I'm afraid C++ is not one of them. 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
