Re: [CMake] relocatable build directory: howto?
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? Would it be enough to make install DESTDIR=/path/to/cache? Michael -- 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
Re: [CMake] relocatable build directory: howto?
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. -- 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
Re: [CMake] relocatable build directory: howto?
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 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. Maybe you could cache those directories instead of the build tree, or was there something else you still needed from the build tree? Clint -- 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
Re: [CMake] relocatable build directory: howto?
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
Re: [CMake] relocatable build directory: howto?
On 05/05/2012 09:59 PM, Dave Abrahams wrote: [...] ...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). ;-) That's what I actually meant with the DESTDIR idea. Sorry I didn't expand further on that. [...] 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. Yep, it's a cozy place :-D Michael -- 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
[CMake] relocatable build directory: howto?
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, -- 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
