[CMake] relocatable build directory: howto?

Dave Abrahams dave at boostpro.com
Sat May 5 15:59:53 EDT 2012


on Sat May 05 2012, Clinton Stimpson <clinton-CsSkQS5UgvVWk0Htik3J/w-AT-public.gmane.org> wrote:

> On May 5, 2012, at 5:52 AM, Dave Abrahams wrote:
>
>> 
>> on Sat May 05 2012, Michael Wild <themiwi-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org> wrote:
>> 
>>> On 05/05/2012 07:25 AM, Dave Abrahams wrote:
>>>> 
>>>> I need to preserve the built-but-not-yet-installed state of some
>>>> projects, and the tool I'm driving CMake with moves the result of every
>>>> build step from a read-write build directory into a readonly cache.  The
>>>> result is that the generated cmake_install.cmake files no longer work,
>>> 
>>>> because they are full of absolute paths.  I wrote a simple program to
>>>> adjust the paths in the cmake_install.cmake files as a postprocessing
>>>> step, replacing $CWD, where it is found, with a cmake variable.  The
>>>> only problem: on my Mac, /tmp is a symlink to /private/tmp, and in some
>>>> scenarios the absolute path in cmake_install.cmake is the short one
>>>> wheras while $CWD is the long one.  No match :(
>>>> 
>>>> I started to write some code to address this problem, but it's getting
>>>> complex to the point where it seems like "there must be a better way."
>>>> So I ask: is there?
>>>> 
>>>> Thanks in advance,
>>>> 
>>> 
>>> I'm afraid that the answer is no. There is the variable
>>> CMAKE_USE_RELATIVE_PATHS, but that is broken and does not work in
>>> general. Just out of curiosity: Why do you need to cache the build tree
>>> in the first place? 
>> 
>> I'm driving CMake with a package installation system (0install) that
>> doesn't allow for subpackages (it may someday, but that's not supported
>> as of now).  This system installs packages into a cache.  It's
>> undesirable to have to build a cmake package twice just to produce its
>> -dev (on windows, includes import libraries) and -bin (includes
>> DLLs/so's) incarnations.  The way we deal with that now is to make the
>> preinstall (built) state a separate 0install package and let 0install
>> put that in the cache, then come back later and install from that
>> package.
>> 
>> Which reminds me; it would be awesome if there were a way to get cmake
>> to clean everything but the leaves in its dependency graph.  IOW, I'd
>> like to throw out all the .o files after having built libraries.  Is
>> there a way?
>> 
>>> Would it be enough to "make install DESTDIR=/path/to/cache"?
>> 
>> Only if I want to build twice.
>> 
>
> In case its applicable, I just thought I'd mention that you can run
> "cmake -P cmake_install.cmake .... " 

I am in fact using that command to do the final installation...

> if you want to customize the installation of the files, even putting
> the -dev files in one place and the -bin in another, then run you own
> packaging tool on those directories afterwards.

...but I hadn't thought of "installing" everything as part of creating
the pre-installed state and then having the "installed" state draw from
those results.  That's a very interesting idea.  I'll try it, thanks.
The other advantage is that we won't keep a bunch of .o files around in
the cache (though we will still have two copies of the libraries until
we can figure out how to flush the preinstalled state).

> Maybe you could cache those directories instead of the build tree, or
> was there something else you still needed from the build tree?

No, as far as I know, that's going to work.  

P.S. The people on this list are terrific.  I'm very grateful for the
responsive help I've gotten over the past few days.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com



More information about the CMake mailing list