Brandon J. Van Every wrote:
I need some stylistic advice on handling global state. I'm starting to
break my monolithic CMakeLists.txt up into subdirectories. I'm building
the Chicken compiler and I need to do staged builds. A lot of
essentially the same operations, done on itself multiple times so that
it's compiled up to its own most current version.
I realize I can use the cache to pass global state.
Before CMake 2.4 the only way to get information from subdirectories was
to set it as INTERNAL cache variables and then configure again. Now you
can get variable settings from subdirectories using GET_DIRECTORY_PROPERTY.
However it looks like you want to pass information from the top-level
down, which is trivial.
> However, there's
often global state that I don't want the user to modify. Nor do I
really want to clutter the output of CMakeSetup with such extraneous
state. I could mark those variables as advanced, which reduces the
immediately visible clutter, but I don't really want clutter in the
advanced variables either. Also they can still modify them, which is
not what I want. For instance I've got certain constants like the
minimum Chicken build number, and nothing good can come from someone
changing them. I've also got a lot of -D flags from probing the system,
that go into ADD_DEFINITIONS. I don't want the user to mess with 'em,
or run the probes multiple times. I just want to determine them at the
toplevel and then pass them down to subdirectories.
I could include constants via an INCLUDE(global.cmake) file, but I'd
rather have them in the toplevel CMakeLists.txt. Right at the beginning
of it, where a maintainer can easily see what's going on and nothing is
obfuscated.
So how do you pass read-only global state to subdirectory consumers?
There is no such thing as a "read only" variable setting except by
convention. If you set a variable in the top level then all
subdirectories will get that value. However, if one subdirectory
changes it the other children will not see the altered value.
-Brad
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
