Notes
(0015866) Bill Hoffman (manager) 2009-03-31 14:11	I disagree, GLOBing is evil. There is just no good way to monitor a directory for new and deleted files that is efficient. Even if this could be made to work somehow with makefiles, (it would be very slow), as ever build would have to check all directories of the project for new or deleted files, the IDE based stuff like VS IDE and Xcode could never be made to work with this. So, globbing is evil, and should be avoided. It is a quick fix to get something going, but a bad long term solution for a project.

(0015868) MrDoomMaster (reporter) 2009-03-31 14:22	Why is it evil? You're calling it evil but not giving any logical reasons as to why you say this. Please justify your remarks. I'll tell you what's evil... Keeping a manual text-based list of source files is evil. When I delete a file, I have to go edit this CMakeLists.txt file and delete that filename from a list. When I rename a file, I have to go edit another file. Any operation on the filesystem that involves renaming, moving, creating, or deleting a source file requires arbitrarily editing a separate source file. This is evil because it is unmanageable. Globbing is not evil because it provides a sense of manageability. When I use globbing, I no longer have to go edit this other file every time something on the filesystem changes. This is also evil because it is error-prone. We're human beings and we're all untrustworthy. When we have the unnecessary responsibility of manually typing filenames into a manual list in a text file, we run the possibility of mis-typing the name of something or some other anomaly. Ever heard of the open/close principle?

(0015870) Bill Hoffman (manager) 2009-03-31 14:35	Manually keeping track of sources in a text file is not evil because: It has checks. Humans are error prone, and if you forget to remove a file from a CMakeLists.txt file, CMake will give you an error about a missing file right away. If you forget to add a file, the linker will give you an error. If you type the name wrong, you will get an error. Using globbing is evil because: - It can accidentally build files you do not want (can not have temp .c or .cxx files anywhere in a build tree.) - It will not notice if you accidentally remove a file - It is very slow to scan directories. I am thinking if you did this for any large project it would take a significant amount of time to parse the source tree with every build. - It does not integrate into IDE's very well. I don't think any of them VS, Xcode, Eclipse, KDevelop, etc, support the idea of adding a globbing directory. Since CMake is a meta build tool, it is somewhat constrained by the tools it generates for.

(0015873) Wojciech Migda (reporter) 2009-03-31 14:52	just my few cents: manual tracking of source files (either in CMakeLists.txt or a separate file included into CMakeLists.txt) is more in the spirit of CM (Configuration Management). Everything can be versioned, which is good. With globbing I just don't see a clean approach.

(0015874) MrDoomMaster (reporter) 2009-03-31 15:17	Manually keeping track of sources in a text file is not evil because: > It has checks. Humans are error prone, and if you forget to remove a file > from a CMakeLists.txt file, CMake will give you an error about a missing > file right away. If you forget to add a file, the linker will give you an > error. If you type the name wrong, you will get an error. So CMake is doing its job. It's doing error checking. That's great. But when you use globbing you don't have to worry about correcting errors like this. If the errors don't occur in the first place (nor would they have the chance to with globbing), the application becomes more usable. > Using globbing is evil because: > - It can accidentally build files you do not want > (can not have temp .c or .cxx files anywhere in a build tree.) This is why globbing is optional. You can even provide an "exclusion list" which is compared against the globbed list and results in items being removed. Globbing isn't a requirement, it's merely a convenience. Use it if it works for you. > - It will not notice if you accidentally remove a file It's not CMake's responsibility to make sure that users don't accidentally delete files off of their filesystem. > - It is very slow to scan directories. I am thinking if you did this for any > large project it would take a significant amount of time to parse the source > tree with every build. I agree that this is a significant bottleneck. It would be quite hard to find out a portable solution to this. You could create a service that monitors the filesystem in the background, but this is a big overboard and may not be portable. > - It does not integrate into IDE's very well. I don't think any of them VS, > Xcode, Eclipse, KDevelop, etc, support the idea of adding a globbing > directory. Since CMake is a meta build tool, it is somewhat constrained by > the tools it generates for. I'm not sure what you mean here.

(0015875) Bill Hoffman (manager) 2009-03-31 15:23	OK, so we agree, that the implementation of this "feature" is near impossible. :) What I mean by the IDE's is that for all IDE environments that I know about you have to explicitly list out the files that it is going to build, you can not just give it a directory tree and tell it to glob all the source files and build them. It is just not in the work flow for these systems. Anyway, I don't see a way this can work nicely and reliably.

(0015877) MrDoomMaster (reporter) 2009-03-31 16:07	The IDE wouldn't be doing the GLOB, the CMake script would. It would glob a list of files that are then added to the IDE. For our particular case, it would be a nightmare to go through several CMake files and update large lists of 100 or more files. It's a maintenance burden for us. Anyway, I guess we'll have to run the cmake-gui tool after every SVN Update operation. Thanks for taking the time to discuss this Bill.

(0015880) Bill Hoffman (manager) 2009-03-31 16:36	>I agree that this is a significant bottleneck. It would be quite hard to find >out a portable solution to this. You could create a service that monitors the >filesystem in the background, but this is a big overboard and may not be >portable. So, you could do the above outside of CMake. Write a service that monitors the filesystem and when new files are found, it would update a CMakeLists.txt file, and then when you ran make cmake would notice that the CMakeLists.txt file changed.

(0016275) Brad King (manager) 2009-05-01 15:37	Explicit lists of source files do scale. Many large projects with thousands of source files get along just fine. Most of these projects have optional sources that do not always build. These cases are tricky to handle with globbing. Globbing works for some projects and not for others. We explicitly decided to not support dependencies on glob results in CMake. We stand by this decision and do not plan to add first-class support. However, you can get something working with current CMake. ------------------- CMakeLists.txt --------------------------- cmake_minimum_required(VERSION 2.6) project(FOO C) execute_process( COMMAND ${CMAKE_COMMAND} -Dsrcdir=${FOO_SOURCE_DIR} -P ${FOO_SOURCE_DIR}/glob.cmake WORKING_DIRECTORY ${FOO_BINARY_DIR} ) add_custom_command( OUTPUT globbed.txt COMMENT "Globbing source files..." COMMAND ${CMAKE_COMMAND} -Dsrcdir=${FOO_SOURCE_DIR} -Dregen=1 -P ${FOO_SOURCE_DIR}/glob.cmake DEPENDS ${FOO_SOURCE_DIR} ) add_custom_target(prepare DEPENDS globbed.txt) include(${FOO_BINARY_DIR}/srcs.cmake) add_executable(foo ${srcs}) add_dependencies(foo prepare) ------------------- glob.cmake --------------------------- file(GLOB srcs RELATIVE ${srcdir} ${srcdir}/*.c) set(new_srcs "set(srcs \"${srcs}\")") if(EXISTS srcs.cmake) file(READ srcs.cmake old_srcs) string(REGEX REPLACE "[\r\n]+$" "" old_srcs "${old_srcs}") endif() if(NOT "${new_srcs}" STREQUAL "${old_srcs}") file(WRITE srcs.cmake "${new_srcs}\n") if(regen) message("Source list changed...re-running CMake") execute_process(COMMAND ${CMAKE_COMMAND} .) endif() elseif(regen) message("Source list unchanged") endif() file(WRITE globbed.txt "1") ---------------------------------------------------------------- Basically this uses a custom command at build time to glob any time the directory is out of date, but only re-run CMake if the glob result changes. It works in this really simple case but I have not thoroughly tested it.

(0041530) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2009-03-27 21:06	MrDoomMaster	New Issue
2009-03-31 14:11	Bill Hoffman	Note Added: 0015866
2009-03-31 14:11	Bill Hoffman	Status	new => assigned
2009-03-31 14:11	Bill Hoffman	Assigned To	=> Bill Hoffman
2009-03-31 14:22	MrDoomMaster	Note Added: 0015868
2009-03-31 14:35	Bill Hoffman	Note Added: 0015870
2009-03-31 14:52	Wojciech Migda	Note Added: 0015873
2009-03-31 15:17	MrDoomMaster	Note Added: 0015874
2009-03-31 15:23	Bill Hoffman	Note Added: 0015875
2009-03-31 16:07	MrDoomMaster	Note Added: 0015877
2009-03-31 16:36	Bill Hoffman	Note Added: 0015880
2009-05-01 15:37	Brad King	Note Added: 0016275
2016-06-10 14:27	Kitware Robot	Note Added: 0041530
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Relationships