[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