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

[Ben Morgan]

Hi Eli,

On 21 June 2012 21:25, Ateljevich, Eli <eli at water.ca.gov> wrote:

> 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,
>


Could you use an initial cache file - see the "-C <initial-cache>" command
line option for CMake?

Apologies if you've already seen that, but it seems to fit what you're
looking for. The format of the initial cache is CMake script rather than
CMakeCache.txt,
but as it's just set(...) commands with the CACHE option it should be easy
for users to write.

I'm not 100% sure what you need in terms of persistency and precedence, but
variables set in an initial cache file will "take priority over the
project's default values" according to the CMake manaul entry.

Cheers,

Ben.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120622/2d83e321/attachment.htm>