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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
