[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
[cmake-developers] ExternalProject and git clone
Hello,
I'm trying to use ExternalProject to create something like a
super-build that downloads and builds the dependencies (from svn, git
and url) and a few modules of my project (in git repositories), but I
have a major issue:
I'd like to be able to modify files, commit, and push from the external
git repositories, therefore I'm downloading them in a different
directory from the build directory. Unfortunately if I want to rebuild
from the start and I delete the build directory, the repository is
deleted because the time stamps are missing, and then cloned again next
time I run make, due to these lines:
execute_process(
COMMAND \${CMAKE_COMMAND} -E remove_directory \${source_dir}\
RESULT_VARIABLE error_code
)
that are executed unconditionally when gitclone_infofile is newer than
gitclone_stampfile.
Therefore all my changes, branches, additional remotes, etc would be
lost. Also no warning is given to the user that the directory is being
deleted, and this behaviour doesn't seem to be documented anywhere.
I would like to try to write a patch that modifies this behaviour
somehow, for example:
* Skip the clone phase if the source_dir exists and is not in the build
directory
* Have a bool property to skip the clone phase if the directory exists
* Just skip the clone if the directory exists
Does it seem reasonable? Do you think that this could cause other issues?
Regards,
Daniele
--
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
Re: [cmake-developers] Targets for FindGTK2.cmake
Hello Stephen,
Sorry for the delay, but I was on holiday...
On 14/08/13 15:07, Stephen Kelly wrote:
Daniele E. Domenichelli wrote:
I did a few more tests, and it looks like that, at least on my system
and on windows, FREETYPE_LIBRARIES are not required, they are linked to
some other libraries (i.e. cairo) but they don't need to be linked
explicitly
On the other hand, the FREETYPE_INCLUDE_DIR is required, because some
public header includes freetype headers.
Can you confirm that the things used in those cases from the headers are
only defines, enum values, inline functions etc, and not anything that
becomes part of the ABI (such as inheriting from a type etc)? Or, otherwise,
can you determine why the freetype header is in the public headers?
I think I can confirm it... at least on the versions I have on my system
(debian testing) and on windows (gtkmm installer), the only file
included in GTK2 ( related libraries) include files seems to be
ft2build.h that includes freetype/config/ftheader.h that contains only
macros + one more include, but only when freetype is built. Therefore
I'm quite sure that it is not necessary to link libfreetype explicitly.
This is another build machine on the dashboard (SunOS5.9-CC) where
FindFreetype causes issues.
http://open.cdash.org/testDetails.php?test=206968805build=3019758
I'm quite sure now that just not linking FREETYPE_LIBRARY explicitly is
the way to fix this on all the systems... Am I allowed to make a commit
and eventually revert it in order to test on the build machines if it
works on all systems?
On window using gtkmm installer, find_package(Freetype) freetype is not
found, FREETYPE_FOUND is FALSE, FREETYPE_LIBRARY is
FREETYPE_LIBRARY-NOTFOUND, but FREETYPE_INCLUDE_DIR is set correctly
(the headers are installed, but the .lib file is missing)
I'm not sure if this is a bug in FindFreetype (FREETYPE_INCLUDE_DIR
should be unset if freetype was not found?)
Perhaps. If so, maybe that's something FPHSA should do? Seems like a
separate topic though.
Do you mean that the windows gtk installer does not install the .lib file at
all, but does install the include files (because it only uses defines/enums
and doesn't need to link to the thing?)?
It installs the headers and the .dll, but not the .lib. Therefore
libraries and executables already linked with, will find the required
.dll when they are executed, but it is impossible to link new ones.
The includes used by GTK2 only have defines but the other freetype
include files define methods, etc. though, so if one of those is
included directly, the build will fail to find the symbols.
Therefore I believe that I should just look for the 2 include files
required by GTK2 only. FindFreetype already defines
FREETYPE_INCLUDE_DIR_ft2build and FREETYPE_INCLUDE_DIR_freetype2 that
look exactly for these files, and FREETYPE_INCLUDE_DIRS is defined as
set(FREETYPE_INCLUDE_DIRS
${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2})
but I wonder if it is correct to leave this variable set, even if
FREETYPE_FOUND is FALSE.
Anyway I believe that instead of checking for FREETYPE_FOUND, I could
check and use FREETYPE_INCLUDE_DIR_ft2build and
FREETYPE_INCLUDE_DIR_freetype2 directly, and that FREETYPE_INCLUDE_DIRS
should be unset if FREETYPE_FOUND is false
Btw, was there any effort to get the gtk upstream to produce cmake config
files with IMPORTED targets?
Not that I know about, and almost for sure not for GTK2 since afaik the
development is now focused on GTK3
Regards,
Daniele
--
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] Targets for FindGTK2.cmake
Daniele E. Domenichelli wrote:
Hello Stephen,
Sorry for the delay, but I was on holiday...
On 14/08/13 15:07, Stephen Kelly wrote:
Daniele E. Domenichelli wrote:
I did a few more tests, and it looks like that, at least on my system
and on windows, FREETYPE_LIBRARIES are not required, they are linked to
some other libraries (i.e. cairo) but they don't need to be linked
explicitly
On the other hand, the FREETYPE_INCLUDE_DIR is required, because some
public header includes freetype headers.
Can you confirm that the things used in those cases from the headers are
only defines, enum values, inline functions etc, and not anything that
becomes part of the ABI (such as inheriting from a type etc)? Or,
otherwise, can you determine why the freetype header is in the public
headers?
I think I can confirm it... at least on the versions I have on my system
(debian testing) and on windows (gtkmm installer), the only file
included in GTK2 ( related libraries) include files seems to be
ft2build.h that includes freetype/config/ftheader.h that contains only
macros + one more include, but only when freetype is built. Therefore
I'm quite sure that it is not necessary to link libfreetype explicitly.
Ok, great. Thanks for checking that.
This is another build machine on the dashboard (SunOS5.9-CC) where
FindFreetype causes issues.
http://open.cdash.org/testDetails.php?test=206968805build=3019758
I'm quite sure now that just not linking FREETYPE_LIBRARY explicitly is
the way to fix this on all the systems... Am I allowed to make a commit
and eventually revert it in order to test on the build machines if it
works on all systems?
Yes, sometimes there is no other way to get that kind of feedback about
problems reported by the dashboard. Another option of debugging dashboard
problems is asking the operator of the machine to test something.
Generally I think making commits in order to test behavior on a particular
machine is ok if it doesn't cause general disruption on all dashboards
(though I've been guilty of doing that before :) ). Then again, they're not
my machines/hardware :).
On window using gtkmm installer, find_package(Freetype) freetype is not
found, FREETYPE_FOUND is FALSE, FREETYPE_LIBRARY is
FREETYPE_LIBRARY-NOTFOUND, but FREETYPE_INCLUDE_DIR is set correctly
(the headers are installed, but the .lib file is missing)
I'm not sure if this is a bug in FindFreetype (FREETYPE_INCLUDE_DIR
should be unset if freetype was not found?)
Perhaps. If so, maybe that's something FPHSA should do? Seems like a
separate topic though.
Do you mean that the windows gtk installer does not install the .lib file
at all, but does install the include files (because it only uses
defines/enums and doesn't need to link to the thing?)?
It installs the headers and the .dll, but not the .lib. Therefore
libraries and executables already linked with, will find the required
.dll when they are executed, but it is impossible to link new ones.
Ok.
The includes used by GTK2 only have defines but the other freetype
include files define methods, etc. though, so if one of those is
included directly, the build will fail to find the symbols.
I think this is ok. Downstreams will have to link to freetype directly if
they want to use it directly, and nothing newly-breaks as that has always
been the case.
Therefore I believe that I should just look for the 2 include files
required by GTK2 only. FindFreetype already defines
FREETYPE_INCLUDE_DIR_ft2build and FREETYPE_INCLUDE_DIR_freetype2 that
look exactly for these files, and FREETYPE_INCLUDE_DIRS is defined as
set(FREETYPE_INCLUDE_DIRS
${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2})
but I wonder if it is correct to leave this variable set, even if
FREETYPE_FOUND is FALSE.
Something to put to a wider audience in a separate thread I think. I can see
how such behavior could be considered backward incompatible (though the
_FOUND variable should technically be checked).
Anyway I believe that instead of checking for FREETYPE_FOUND, I could
check and use FREETYPE_INCLUDE_DIR_ft2build and
FREETYPE_INCLUDE_DIR_freetype2 directly, and that FREETYPE_INCLUDE_DIRS
should be unset if FREETYPE_FOUND is false
Seems fine to me.
Btw, was there any effort to get the gtk upstream to produce cmake config
files with IMPORTED targets?
Not that I know about, and almost for sure not for GTK2 since afaik the
development is now focused on GTK3
Ok. Thanks for your thorough research on this!
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
