Hi,
What is mentioned here has been implemented in our configuration system
(CMT previously implemented in pure C++/make and currently
re-implemented on top of CMake)
The principle is to add on top of the build system (say CMake, but this
could be plain make, or Waf) a layer that describes the configuration of
your software project in terms of:
- structure (directory structure and functional relationships ie. the
use relationships) as a graph of projects and packages
- constituents (libs, apps, generated docs) and their sources
- parameters for both the build, the packaging and the run
- conditions (tags, contexts) that could be used to select operational
situations
This configuration used to be described in a text file (per package +
per project) filling in a in-memory-database, used to setup the various
build tools, as well as the production tools and to offer query features
to the developer/user.
Nowadays, this approach is being re-implemented using the CMake language
to profit its multiplatform & paralellism capacity.
This approach answers the point you raise here, but also another recent
point on the a-priori knowledge of what/where/how is available in a
given possible large software base.
I would love that the database approach would be natively offered by
CMake (thus offering the pre/post build query facilities)
<http://www.cmtsite.org/>
<git://github.com/ChristianArnault/CMT.git>
Regards,
Christian
Le 21/06/2012 22:25, Ateljevich, Eli a écrit :
Hi,
I was wondering if there is a best practice for providing a file for
user configuration decisions (options, unique flags) that will be more
persistent than the cache? I have a project where a dozen or two
algorithmic decisions have to be made. I find that this is just enough
that cache overwrites cause me fear. I could do this on the
environment, I suppose, but most of my users prefer a small list of
name-value pairs for decisions that are pretty stable for them.
I couldn't find anything on this. The concept is alluded to by a 2001
email about INCLUDE by Bill Hoffman:
It could be used like this:
INCLUDE (${PROJECT_BINARY_DIR}/UserCacheSettings.txt OPTIONAL)
This would allow the user to pre-set values for the Cache file, but still
be able to delete the Cache file.
But I wasn't sure about the mechanics of this. When would it have to
be read to fulfill this role and what does "pre-set" really mean in
light of that as far as precedence if there are duplicate entries?
Wouldn't everything that could be set have to be something that will
also appear in CMakeCache.txt? I assume the format would be just like
CMakeCache.txt? ...which would be ideal.
Thanks,
Eli
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
--------------------------------------------
| Christian Arnault |
| LAL Bat 200 pièce 03a |
| 91405 Orsay CEDEX |
| phone : (33) 1 64 46 84 24 |
| gsm : (33) 6 77 27 62 30 |
| fax : (33) 1 69 07 94 04 |
| e-mail : christian.arna...@lal.in2p3.fr |
--------------------------------------------
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
