<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
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)<br>
<br>
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:<br>
<br>
- structure (directory structure and functional relationships ie.
the use relationships) as a graph of projects and packages <br>
- constituents (libs, apps, generated docs) and their sources<br>
- parameters for both the build, the packaging and the run<br>
- conditions (tags, contexts) that could be used to select
operational situations<br>
<br>
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.<br>
<br>
Nowadays, this approach is being re-implemented using the CMake
language to profit its multiplatform & paralellism capacity.<br>
<br>
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.<br>
<br>
I would love that the database approach would be natively offered by
CMake (thus offering the pre/post build query facilities)<br>
<br>
<a class="moz-txt-link-rfc2396E" href="http://www.cmtsite.org/"><http://www.cmtsite.org/></a><br>
<git://github.com/ChristianArnault/CMT.git><br>
<br>
Regards,<br>
Christian<br>
<br>
<br>
<br>
Le 21/06/2012 22:25, Ateljevich, Eli a écrit :
<blockquote
cite="mid:67CC54752B3F8D43ACD7E3AD455162630B6208C856@mrsbmapp20306.ad.water.ca.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I couldn’t find anything on this. The
concept is alluded to by a 2001 email about INCLUDE by Bill
Hoffman:<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New"">It
could be used like this:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New"">INCLUDE
(${PROJECT_BINARY_DIR}/UserCacheSettings.txt OPTIONAL)<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New"">This
would allow the user to pre-set values for the Cache file,
but still<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New"">be
able to delete the Cache file.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Eli<o:p></o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
Visit other Kitware open-source projects at <a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>
Please keep messages on-topic and check the CMake FAQ at: <a class="moz-txt-link-freetext" href="http://www.cmake.org/Wiki/CMake_FAQ">http://www.cmake.org/Wiki/CMake_FAQ</a>
Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
--------------------------------------------
| 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 : <a class="moz-txt-link-abbreviated" href="mailto:christian.arnault@lal.in2p3.fr">christian.arnault@lal.in2p3.fr</a> |
--------------------------------------------
</pre>
</body>
</html>