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. 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? > > > Cheers, > Brandon Van Every
Maybe SET INTERNAL is what you are looking for. -- Filipe Sousa
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
