[cmake-developers] Getting a list of files to install and their destination
Hi there,
On the QtCreator list recently there was a discussion about installing
projects which use cmake to device targets:
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995
The want to transfer files without invoking make install. I think the only
reason for that is because it could be a lengthy operation (with cmake I'm
not so sure - I think cmake doesn't reinstall something that is not
changed).
Additionally, my several points that installation may be necessary were not
addressed:
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995/focus=8997
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995/focus=9008
The solution they seem to want to require is maintaining the list of files
to install in parallel to the install() commands.
I was wondering if there was some way that cmake could generate a list of
files and destination for them with a built-in make-target? I guess the
limitation of that is that install(SOURCE) and install(CODE) can do
arbitrary things. I've never used them, but presumably they would use
file(COPY) to put files in the installation location using
${CMAKE_INSTALL_PREFIX} ? That probably makes the built-in make-target to
generate a list of files and destinations a non-starter.
Am I right in saying that even for remote deployment, cmake will not
transfer files which are not changed? And therefore the worry about that
from the creator folks is unfounded? And the only solution that actually
works for them is installing to a tmp location, given the possible existence
of install(SCRIPT) and install(CODE)?
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Getting a list of files to install and their destination
On 09/05/2013 08:14 AM, Stephen Kelly wrote: limitation of that is that install(SOURCE) and install(CODE) can do arbitrary things. Yes. There are also modifications made to the installed files for things like runtime path. Installation is procedural, not declarative. There is no way to predict the results without just doing it. Am I right in saying that even for remote deployment, cmake will not transfer files which are not changed? If the modification times are identical then CMake will not update the installed file. If they are different, in either direction, CMake will install and make the modification times the same. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Getting a list of files to install and their destination
2013/9/5 Brad King brad.k...@kitware.com: On 09/05/2013 08:14 AM, Stephen Kelly wrote: limitation of that is that install(SOURCE) and install(CODE) can do arbitrary things. Yes. There are also modifications made to the installed files for things like runtime path. Installation is procedural, not declarative. There is no way to predict the results without just doing it. Non mentioning INSTALL(DIRECTORY) INSTALL(FILES) INSTALL(PROGRAMS) All those INSTALL(xxx) commands ends-up in FILE(INSTALL ...) command inside generated cmake_install.cmake files. You'll discover the FILE(INSTALL...) command has undocumented internal parameters which are used in cmake_install.cmake. Am I right in saying that even for remote deployment, cmake will not transfer files which are not changed? If the modification times are identical then CMake will not update the installed file. If they are different, in either direction, CMake will install and make the modification times the same. Which implies CMake would have to find a way to check modif' times on the remote target AND ensure that host and target share the same time reference. If you want to avoid that you'll have to maintain some local (to the host) mean which proves that currently built file/taregt is not different from the previously installed one. A possible mean would be to build a hash of each installed file inside the install step. In the 3 options described there: http://thread.gmane.org/gmane.comp.lib.qt.creator/8995 1) use CPack 2) use make install to tmp and deploy are almost the same because CPack precisely install to a temp location before building the package, so that creating the CPack generator that does: a) deploy b) create some CMakeDeployment.txt seem quite easy and similat to 2). CPack usually throw away its tmp dir before each packaging request, however a specific generator may certainly be taught not to do so in order to spare some time and rely on install to do this in an appropriate manner. This CPack Deploy generator would then be able to only transfer the updated files. Note that following the same idea CMake already creates install_manifests.txt file. You can grep the source for CMAKE_INSTALL_MANIFEST and see that is is handled by the FILE( ..) command. The manifest file is create by the very end of toplevel cmake_install.cmake script after all FILE(...) have run. -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
