On 29.05.2013 22:59, 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: [...] > >> 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?
Also, very astonishing to me is the fact that after apparently finding file(GLOB) in the documentation, you clearly didn't read the whole paragraph. It's right there: >> We do not recommend using GLOB to collect a list of source files >> from your source tree. If no CMakeLists.txt file changes when a >> source is added or removed then the generated build system cannot >> know when to ask CMake to regenerate. As you are so fond of clear violations: You failed to RTFM... (http://en.wikipedia.org/wiki/Rtfm) Besides, you seem to be very sure that CMake is the *only* tool that prefers explicit source file listing. Have you ever used any of the popular IDE's? Visual Studio? Xcode? Eclipse? They all create explicit list of files in their projects. What are the (not so serious) pros and cons of GLOB, even if it worked the way you think it should? Pro: * laziness Con: * laziness * extremely error prone: - picks up scratch files - works for you but breaks for others because you forgot to commit a file - breaks for you because the other dude forgot to commit his file * makes it unnecessarily difficult to exclude files from the build - temporarily: for testing (you'd need to move the file away and then remember to move it back; error prone again) - permanently: dependent on the platform, configuration, enabled capabilities etc. And using #ifdef's for this is bad because you still invoke the compiler and waste time to just compile an "empty" file. * when reading the build system code, you have to switch context in order to determine the files included in the build. On the other hand, initially creating and then maintaining an explicit list of files is easy. Initially I usually create the list of files like this using vim: :r !cd $(dirname %); ls **/*.{c,cpp}; ls **/*.{h,hpp} Michael -- 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
