>>> find . -name "*.c" > source_files.txt >>> edit source_files.txt and put that list of files exiplicitly into a >>> CMakeLists.txt file. >>> >>> file(GLOB is a bad way to get source lists for CMake. CMake has >>> no way of knowing when new files have been put in the directory. >> >> But unless I am missing a fundamental feature somewhere, GLOB still >> seems to be the better alternative. While it may not intrinsically >> know when new files have appeared on the filesystem, the programmer >> can simply re-run the CMake command to get an updated project with >> the newly added source files without editing the CMakeLists.txt >> file directly. > >Yes but when he add a source file, he won't necessarily remember he >MUST rerun CMake manually [...] > >Whereas with hard-written sources files in CMakeLists.txt, the user >will get accustomed to "simple" CMakeList.txt editing [...] > >[...] > >It usually looks like a better alternative (but I may be wrong) when >you are in the process of converting several project to CMake and you >end-up writing a lot of boring CMakeLists.txt in the startup process >:=)
Actually, when I was last faced with this task I decided the easier alternative for me was to cut and paste a lot of boring directory listings into my CMakeLists.txt files. (This was in a much earlier version of CMake, and IIRC there was some problem with file globbing back then that was fixed soon afterward.) The reason for my choice at that time was user acceptance. I had a brief window of opportunity to introduce a new build system based on CMake, which did not give me time to train all the developers in CMake before deploying it. One of the first objections I received was that it was "much harder" to add, remove, or rename source files in CMake than via the Visual Studio interface. So I made it a "pushbutton" process: the developer just had to run a script named something like MakeWorkspace.bat. Besides the project developers themselves, I also had users who needed to be able just to build the project without doing any development on it. I actually got in trouble with those users on account of the one directory where I had listed the source files individually instead of "globbing" them. The problem was solved when we "globbed" that directory too. I've had second thoughts about all this, for example the other day when someone forgot to tell a developer newly introduced to this project that he needed to run the script after adding source files--that is, we forgot until he came to me asking about his link errors. On the other hand, it takes very little time for people to develop new habits that tell them when to re-run the script. I'm probably going to change some things about the build procedure sooner or later, but I don't know if or when this will be one of them. The conclusion for me is that when I write a CMakeLists.txt file for a personal project, I never "glob" the files; but the build design of a long-running project needs to account for who is working on it and what procedures will work best for them. That may imply listing the files explicitly, but it could conceivably imply "globbing" them. David Karr _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake