[CMake] Text user configuration (features, flags) that is more persistent than cache?

[Christian Arnault]

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.arnault at lal.in2p3.fr |
--------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120622/913e6ccc/attachment-0001.htm>