Craig Scott wrote: > I'm coming in half way to this discussion, so apologies if my comments > interspersed below are not so well related to the core topic of > discussion.
Hi Craig, Thanks for your input. > Consider the following example which perhaps better shows that this > problem may not be as uncommon as first thought: > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption") > add_library(foo ...) > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse") > > I think most developers probably expect foo to not have the -somethingElse > option when it is compiled, but I believe it would have it. The difference occurs depending on when the value is read. See my CMAKE_CXX_STANDARD example below. > If I understand things correctly, directory *properties* don't typically > have this unexpected behaviour as their value at the time of defining the > targets is used, not at the end of that directory's processing. It all depends on when the value is read. Something that is read at configure-time appears to have immediate effect, regardless of whether it is a 'directory property' or a set() 'definition'. When something that is read at generate-time (such as CMAKE_CXX_FLAGS) it takes on the value at the end of the directory. You might be referring to things like this, which are still 'definitions' not 'directory properties': set(CMAKE_CXX_STANDARD 11) # Reads CMAKE_CXX_STANDARD 'now' at configure time add_executable(foo ...) set(CMAKE_CXX_STANDARD 14) # Reads CMAKE_CXX_STANDARD 'now' again! add_executable(bar ...) The important distinction is where in the CMake C++ code the cmMakefile::GetDefinition call occurs - generate-time code or configure-time code. This is a sideline just for your information. What this thread is really about is whether things should be read 'only once' or 'once per directory', and whether the CMake C++ code chooses one or the other deliberately or accidentally, and what impact that has on maintainability and refactoring. > this behaviour of using the > variable's value at the end of the directory processing is likely a > surprise to many and probably already causes some head-scratching until > devs figure it out. Is the problem being discussed here relating to > CMAKE_CODELITE_USE_TARGETS > much different? It seems like a related example to me. The CMAKE_CODELITE_USE_TARGETS feature is trying to be related to a project() command, but it is read at the end of the directory. Usually, I would think that is not a problem the way most people write project() commands and set these kinds of settings. However, in the general sense of how 'global' settings should work, I think things could be better. >> Those are not problems users or contributors adding features encounter, >> so that might affect a perception of 'big'ness. These problems only >> bubble up during refactoring or under longer-term maintenance when the >> true semantics of the code become known. >> > > Perhaps a bit more common than that, as the above example suggests. Yes, those kinds of examples are the things that I would expect to arise during maintenance, perhaps several releases after a feature hits master. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers