[Cmake] feature request - separate user and system cmake cache files

[Tony Pan]

Hi, Ken,
I tried the solutions you suggested.  The -C and -D approaches do not
work for me in that the values get overridden during the cmake configure
process.
 
What I am trying to do is basically to script a build, and Fred's
approach (with a minimalistic CMakeCache.txt file) works.    I am aware
this is not optimal, but for now, it suffices.  Thanks for your help.
 
Tony 

-----Original Message-----
From: Ken Martin [mailto:ken.martin at kitware.com] 
Sent: Monday, March 10, 2003 4:05 PM
To: tpan at bmi.osu.edu; cmake at public.kitware.com
Subject: RE: [Cmake] feature request - separate user and system cmake
cache files



Hey Tony,

 

"cmake -CInitFile"  tells cmake to load a CMakeLists file prior to
startup. Use that file to set your common values.  So something like
"cmake -CTonysConfig.cmake" would accomplish what you want. I believe
the option is available on all the GUI's as well as from the command
line.

 

For our nightlies we use scripts that either do

 

cmake -DVALUE=TYPE:SETTING -DVALUE2=TYPE:SETTING

 

or what Fred suggested. We have a mixture of both. We really don't want
people editing the cache directly for a number of reasons.

 

Thanks

Ken

 

-----Original Message-----
From: cmake-admin at public.kitware.com
[mailto:cmake-admin at public.kitware.com] On Behalf Of Tony Pan
Sent: Monday, March 10, 2003 2:35 PM
To: cmake at public.kitware.com
Subject: [Cmake] feature request - separate user and system cmake cache
files

 

I apologize if this has already been brought up.  I think it would be
helpful if the CMakeCache.txt file can be split into a user file and a
system file.  The motivation for the request is that I have been setting
up several build environments, and typing in the same stuff over and
over is getting old very quickly.  It'd be nice if I can just copy the
user config file, make a few modifications, and then rerun cmake to
regenerate the system configs.  This would be useful for setting up
testing environments.  In addition, having separate cache files would
make updating src code to new versions easier and less prone to dirty
cache, as I'd only need to blow away the system cache.

 

Thanks.

 

Tony 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20030311/a5bca318/attachment.html>