Re: [CMake] PROTECTED_AT: double encoding in CPack?
On Fri, Feb 28, 2014 at 5:27 PM, Ian Monroe i...@monroe.nu wrote: I'm getting errors like: error: File not found: /home/ian/atlassian/quipchat-installer/build64/quipchat-prefix/src/quipchat-build/_CPack_Packages/Linux/RPM/hipchat-2.1.60090-Linux/opt/HipChat/lib/QtQuick/Controls/Styles/Base/images/arrow-up@protected...@2x.png When generating an RPM with CPack. Which is true, that file doesn't exist, the filename is actually arrow...@2x.png. I found this bug: http://public.kitware.com/Bug/view.php?id=14063 Which seems to have introduced this PROTECTED_AT. Don't really understand how that patch was supposed to work. :) I'm building on Debian 7, which has RPM 4.11.1. Appears to be new enough. Reverting the commit resolved the issue for me. It looks like the patch was written under the assumption that configure_file processes @var@'s recursively, so if a @var@ expands to a string with more @var@'s those get processed as well. But that doesn't appear to be the case. Ian -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] PROTECTED_AT: double encoding in CPack?
I'm getting errors like: error: File not found: /home/ian/atlassian/quipchat-installer/build64/quipchat-prefix/src/quipchat-build/_CPack_Packages/Linux/RPM/hipchat-2.1.60090-Linux/opt/HipChat/lib/QtQuick/Controls/Styles/Base/images/arrow-up@PROTECTED_AT @2x.png When generating an RPM with CPack. Which is true, that file doesn't exist, the filename is actually arrow...@2x.png. I found this bug: http://public.kitware.com/Bug/view.php?id=14063 Which seems to have introduced this PROTECTED_AT. Don't really understand how that patch was supposed to work. :) I'm building on Debian 7, which has RPM 4.11.1. Appears to be new enough. Thanks, Ian -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Save stripped debugging information
On Thu, Sep 22, 2011 at 12:25 AM, Lukas Anzinger l.anzin...@gmail.comwrote: Hi, I'm aware of the option CMAKE_BUILD_TYPE with which I can tell if I want to include debugging information or not. A very useful feature of the program objcopy is, to not strip debugging information from a file but to split it from it so that you can release a program without debugging information but can later debug it if you put the split debugging files in certain directories (more at http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html). Is there a CMake way to do this? It's a year and a half later. Did something come of this? I just built Qt on Linux and with the right options it gives .debug files. That's really nice. :) Right now I have something working in my project where it builds with debug info, extracts the debug info (I'm using Google Breakpad) and then strip the binary. But a ReleaseWithSeperateDebugInfo option would be the ideal. Mostly for peace of mind since I'm not a big fan of my stripping hack. ;) Ian -- 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] portable way of linking (external) libs statically/dynamically/for dlopen
On Mon, Apr 29, 2013 at 11:13 AM, Philippe Cerfon philc...@gmail.comwrote: Hi. I've always thought one of the main objectives of cmake was being portable, right? So I was looking for a way to let the user (i.e. the person building a project) choose how he wan't to link each external library (i.e. not the ones built as targets by my project), depending on what that lib supports and (when my own code supports it:) dynamically loaded via e.g. dlopen. But it seems that I cannot even tell CMake (in a portable way) that it should use static or dynamic linking for some external lib (not to talk about the core libs like libc or libstdc++). Of course I can work around this any manually search for e.g. .so and .a files... but that woudln't be portable anymore... not to talk about different linkage options per linker... so ideally CMake should (IMHO) take care of all this (for each supported platform/linker). Am I missing something? Or is that just som major deficiency in the portable-part? Static linking of external libraries is just a weird thing to do. Ian -- 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] clear compile flags for a file
So I have the same problem as the person in this old thread: http://www.cmake.org/pipermail/cmake/2009-August/031671.html I want to add some compile flags (currently using add_definitions) but they mess up the rc.exe resource compiler. Doing something like: set_source_files_properties(hipchat.rc PROPERTIES COMPILE_DEFINITIONS )set_source_files_properties(hipchat.rc PROPERTIES COMPILE_FLAGS ) doesn't work, I guess set_source_file_properties is only appending. setting CMAKE_CXX_FLAGS didn't seem to work at all. -- 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] clear compile flags for a file
On Wed, Apr 10, 2013 at 1:37 PM, Ian Monroe i...@monroe.nu wrote: So I have the same problem as the person in this old thread: http://www.cmake.org/pipermail/cmake/2009-August/031671.html I want to add some compile flags (currently using add_definitions) but they mess up the rc.exe resource compiler. Doing something like: set_source_files_properties(hipchat.rc PROPERTIES COMPILE_DEFINITIONS )set_source_files_properties(hipchat.rc PROPERTIES COMPILE_FLAGS ) doesn't work, I guess set_source_file_properties is only appending. setting CMAKE_CXX_FLAGS didn't seem to work at all. Ok I figured out you need to pass CMAKE_CXX_FLAGS a string. So now I have it all working. I still wonder if the state-of-the-art has changed since 2009. Is there a way to clear definitions from a file? -- 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] CPack source packaging
On Wednesday, March 06, 2013 01:01:07 Szőts Ákos wrote: Dear list members, I made a project with CMake (2.8.10) on Linux and want to use CPack to create its source .tar.bz2 file. The task is really simple: copy all of the *.cpp and *.h files into the .tar.bz2 file preserving the directory structure. What about the CMakeLists.txt? :) Although sounds really simple, I've yet to find a solution. The problems are: - In the source directory goes the development also, producing a lot of other files which are unneeded. - With CPACK_SOURCE_IGNORE_FILES variable I can exclude some files, but without the regexp positive lookahead feature I cannot say exclude everything, except for the *.cpp and *.h - Other solution would be an external command (eg. find and cp) to copy all the files into an other temporary directory and set that directory as the source directory. The drawback: there's no way to tell in CMakeLists.txt which is the current CPack generator, so I simply can't write if (CPACK_GENERATOR STREQUAL TBZ2), because CPACK_GENERATOR is empty at cmake . time. So the find and copy command either ran all the time or not even once. - As a last resort I can execute a bz2 command which would do all the necessary things, but that would run every time (see the problem above). The command I issue to generate the source: cpack --config CPackSourceConfig.cmake Is there a simple solution to achieve this? I think you should use your source code control system for this. It already knows which files are source. Git has a git archive command for this Ian -- 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] CPack: Installing applications in separate folders
On Mon, May 21, 2012 at 3:38 PM, Eric Noulard eric.noul...@gmail.com wrote: 2012/5/21 David Cole david.c...@kitware.com: On Mon, May 21, 2012 at 2:05 PM, noru...@me.com wrote: But what about other systems like linux. If I have an executable and shared libraries for example. Then it is possible to install it under /opt/myproject, but it is not possible to install the executable under /usr/bin and the shared libraries under /usr/lib? Or did I misunderstood something? But you don't build an NSIS installer based on those. And installing lib in /usr/lib and exe in /usr/bin IS possible because the 2 path shares the /usr prefix. On Linux if you build an RPM or DEB package which contains various prefix (/usr /opt etc..) you either get a non relocatable package or decide that some files are special like config files. So I have a question tangential to this old thread: how *do* you install some special config files? I want my package to be mostly installed under /opt, but still drop the relevant .desktop and .png files into /usr/share/application, /usr/share/icons/... Thanks, Ian -- 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] CPACK_STRIP_FILES not working for files not built by project
On Sun, Jan 20, 2013 at 11:46 PM, Eric Noulard eric.noul...@gmail.com wrote:
Right I forgot one important bit, CPack plays with CMAKE_INSTALL_PREFIX and
DESTDIR
could you try that:
execute_process(COMMAND ls $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}
OUTPUT_VARIABLE lsresults)
Yep thanks. That did it!
Ian
--
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] CPACK_STRIP_FILES not working for files not built by project
My project is currently producing 100mb RPM/Deb's, but with stripped binaries it should clock in at about 20mb. I have CPACK_STRIP_FILES set to true. Notably when I do make install/strip that doesn't seem to work either. Looking more closely, I see that install/strip does work for the files built by the project, but not some of the external libraries I'm installing as well (so that they get picked up by CPack.) Any suggestions? Adding strip manually is doable, just a bit troublesome since I can't do cmake configuration time stuff like file(glob. Thanks, Ian Monroe -- 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] CPACK_STRIP_FILES not working for files not built by project
On Sun, Jan 20, 2013 at 3:13 AM, Eric Noulard eric.noul...@gmail.com wrote: 2013/1/20 Ian Monroe i...@monroe.nu: My project is currently producing 100mb RPM/Deb's, but with stripped binaries it should clock in at about 20mb. I have CPACK_STRIP_FILES set to true. Notably when I do make install/strip that doesn't seem to work either. Looking more closely, I see that install/strip does work for the files built by the project, but not some of the external libraries I'm installing as well (so that they get picked up by CPack.) This is the expected behavior, CPack does not do the stripping it forwards it to CMake. The doc says it all: cpack version 2.8.10.20130117-g2b545 CPACK_STRIP_FILES List of files to be stripped Starting with CMake 2.6.0 CPACK_STRIP_FILES will be a boolean variable which enables stripping of all files (a list of files evaluates to TRUE in CMake, so this change is compatible). It's a boolean toggle. Basically CPack forward the stripping to the install step so this is no surprise that you external target/files/libs are not stripped I guess they should be stripped before being imported in your project. Well I have another step where I extract the debug symbols. :) And I just want to coordinate all this in one place (eg my cmake files). How do you integrate those external files? As IMPORTED TARGET then INSTALL(TARGETS or do you INSTALL(FILES ?? or ?? Just a plain INSTALL(FILES...) Any suggestions? Adding strip manually is doable, just a bit troublesome since I can't do cmake configuration time stuff like file(glob. The stripping code should be added to the installation time code as is it is with CMake handled target. May be it's doable by creating a CMake script which will do the extra stripping on the appropriate list of files. Then you'll have to: insttall(SCRIPT ...) The appropriate solution heavily depends on how you get external files installed along with your CMake handled targets. Yea I guess I could do install(CODE...) and then a file(GLOB...) would actually work. Ian -- 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] CPACK_STRIP_FILES not working for files not built by project
On Sun, Jan 20, 2013 at 10:47 AM, Ian Monroe i...@monroe.nu wrote:
Yea I guess I could do install(CODE...) and then a file(GLOB...) would
actually work.
Actually not so sure how to do it, since if I write something like this:
install( CODE file(GLOB installedLibrares ${CMAKE_INSTALL_PREFIX}/lib/*.so)
execute_process(COMMAND strip ${installedLibrares})
)
It will only affect the files that were make installed, not the files
used by CPack, correct? Since I don't know how to access those files,
CMAKE_INSTALL_PREFIX doesn't change during CPack-time even though it
installs somewhere else.
--
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] CPACK_STRIP_FILES not working for files not built by project
On Sun, Jan 20, 2013 at 1:03 PM, Eric Noulard eric.noul...@gmail.com wrote: I'd rather create a script strip-all-installed-file.cmake and do install(SCRIPT strip-all-installed-files.cmake) then the content of strip-all-installed-files.cmake does not need escaping. Thanks for the tip. I'll do this now. :) Ian -- 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] CPACK_STRIP_FILES not working for files not built by project
On Sun, Jan 20, 2013 at 1:03 PM, Eric Noulard eric.noul...@gmail.com wrote:
It will only affect the files that were make installed
not the files used by CPack ?
CPack does call cmake -P cmake_install.cmake so
**all files** packaged by CPack are somehow **installed** previously.
CMAKE_INSTALL_PREFIX has a CPack-time value which is set by CPack
when installing file on the CPack-private location so you should escape it
in order to prevent its evaluation at CMake-time, i.e.
It doesn't seem to work. CMAKE_INSTALL_PREFIX during CPack/RPM time is
apparently being set to CPACK_PACKAGING_INSTALL_PREFIX, ie a directory
that doesn't exist since it's just for the resulting RPM. (Unless
CPack is running inside a chroot of it's own making at that point??)
So with something like this in the strip-all-installed-files.cmake
script being executed via install(SCRIPT...):
execute_process(COMMAND ls ${CMAKE_INSTALL_PREFIX} OUTPUT_VARIABLE lsresults)
I get an error that the directory doesn't exist.
Ian
--
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] CPACK_STRIP_FILES not working for files not built by project
On Sun, Jan 20, 2013 at 3:44 PM, Ian Monroe i...@monroe.nu wrote:
On Sun, Jan 20, 2013 at 1:03 PM, Eric Noulard eric.noul...@gmail.com wrote:
It will only affect the files that were make installed
not the files used by CPack ?
CPack does call cmake -P cmake_install.cmake so
**all files** packaged by CPack are somehow **installed** previously.
CMAKE_INSTALL_PREFIX has a CPack-time value which is set by CPack
when installing file on the CPack-private location so you should escape it
in order to prevent its evaluation at CMake-time, i.e.
It doesn't seem to work. CMAKE_INSTALL_PREFIX during CPack/RPM time is
apparently being set to CPACK_PACKAGING_INSTALL_PREFIX, ie a directory
that doesn't exist since it's just for the resulting RPM. (Unless
CPack is running inside a chroot of it's own making at that point??)
So with something like this in the strip-all-installed-files.cmake
script being executed via install(SCRIPT...):
execute_process(COMMAND ls ${CMAKE_INSTALL_PREFIX} OUTPUT_VARIABLE lsresults)
I get an error that the directory doesn't exist.
Or to pose the question more broadly:
I'm pretty sure the directory I actually want with (for instance) RPM
gen is this one:
build/_CPack_Packages/Linux/RPM/project-1.87.0-Linux/${CPACK_PACKAGING_INSTALL_PREFIX}
is there a variable with that in it?
--
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] using find_library with a ExternalProject
On Mon, Oct 22, 2012 at 6:07 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 10/21/2012 10:20 PM, Ian Monroe wrote:
So I had code like:
include(ExternalProject)
ExternalProject_Add(
mockcpp
DOWNLOAD_COMMAND hg clonessh://h...@bitbucket.org/godsme/mockcpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${MOCKCPP_PREFIX}
UPDATE_COMMAND hg pull
)
find_library(MOCKCPP_LIBRARY
NAMES
mockcpp
PATHS
${MOCKCPP_PREFIX}/lib
NO_DEFAULT_PATH)
This worked just fine until I used it on a fresh build. Then cmake
wouldn't finish since at cmake-time the library doesn't exist.
This is a limitation of External project, you can not mix external project
with non-external project CMake code and have it work in a portable manner.
Since external project defers download, configure and build until build
time, there is nothing for the find_library to find at configure time
because the code is not even there in many cases.
The way to do it is to change the rest of the project into external
projects:
ExternalProject_Add(mockcpp)
ExternalProject_Add(MyProject)
Inside MyProject, you call find_library because mockcpp will be downloaded,
configured, and built by then.
So what was the target use-case for ExternalProject? From the name it
sounds like it was meant exactly for making your non-external project
(aka your project) be able to pull in dependencies from external
projects.
To make the project itself an external project gives up a lot of
flexibility in cmake configuration. And would just plan mess up my
source tree. :)
Ian
--
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] using find_library with a ExternalProject
So I had code like:
include(ExternalProject)
ExternalProject_Add(
mockcpp
DOWNLOAD_COMMAND hg clone ssh://h...@bitbucket.org/godsme/mockcpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${MOCKCPP_PREFIX}
UPDATE_COMMAND hg pull
)
find_library(MOCKCPP_LIBRARY
NAMES
mockcpp
PATHS
${MOCKCPP_PREFIX}/lib
NO_DEFAULT_PATH)
This worked just fine until I used it on a fresh build. Then cmake
wouldn't finish since at cmake-time the library doesn't exist.
So for now I just have switched to manually specify the library name
(${MOCKCPP_PREFIX}/lib/libmockcpp.a). But that's not portable at all,
I need to somehow tap into the platform independent foo inside
find_library. The library in question here is actually using cmake, so
another option would be to somehow use the targets of the external
project, but I didn't see a way to do it (ExternalProject_Get_Property
doesn't seem to be intended for that).
Thanks,
Ian Monroe
--
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] How to make a ProjectConfig.cmake
To create my QyotoConfig.cmake I need to know the full path of a library so that I can set a variable like QYOTO_LIBRARY. This is pretty standard requirement right? Its what we're supposed to do in *Config.cmake's? So anyways, how do I that? The only target property that hasn't returned NOTFOUND is LOCATION, which unhelpfully returns the location of the library in the build directory. I could parse this to get the file name, and then append it to the library install location... but that seems like such a hack. Feels like I'm doing something wrong if I need to use a hack to do something standard. I looked at install(EXPORT which could work, but it seems to include a lot more information then is needed. I just want to set a variable with the full path to a library. Ian ___ 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] How to make a ProjectConfig.cmake
On Thu, Dec 30, 2010 at 08:08, Michael Hertling mhertl...@online.de wrote: On 12/30/2010 11:33 AM, Ian Monroe wrote: To create my QyotoConfig.cmake I need to know the full path of a library so that I can set a variable like QYOTO_LIBRARY. This is pretty standard requirement right? Its what we're supposed to do in *Config.cmake's? Yes. So anyways, how do I that? The only target property that hasn't returned NOTFOUND is LOCATION, which unhelpfully returns the location of the library in the build directory. I could parse this to get the file name, and then append it to the library install location... but that seems like such a hack. Feels like I'm doing something wrong if I need to use a hack to do something standard. Usually, I'd have a template QyotoConfig.cmake.in which contains FIND_LIBRARY(QYOTO_LIBRARY qyoto PATHS @CMAKE_INSTALL_PREFIX@/lib NO_DEFAULT_PATH ) and is processed by CONFIGURE_FILE(). If the library is installed with INSTALL(TARGETS qyoto RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find the library right at the installation location but nowhere else, and the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll, are also handled correctly. I looked at install(EXPORT which could work, but it seems to include a lot more information then is needed. I just want to set a variable with the full path to a library. Nevertheless, the imported-targets approach, i.e. the combination of INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an appropriately set up config file, is much more powerful and should be preferred, IMO; see [1] for more information. BTW, as the export file defines the imported targets, its inclusion in the config file should possibly be protected in a suitable way to avoid fatal redefinitions. The context I'm coming from is that I'm developing stuff that is distributed by Linux distributions. The export file has information about what the target is dependent on, including full paths. That feels like a bad thing to me. What was true about dependencies when a package was being built on a build server might not be true later. ...or maybe its fine? Can someone point me to an example of a package distributed by linux distros that uses this feature? Would make me feel better to know that I'm not the first person to use it. :) I'll probably go with your first solution, but this export feature is interesting since it looks less cumbersome to use. Thanks, Ian ___ 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] How to make a ProjectConfig.cmake
On Thu, Dec 30, 2010 at 09:42, Michael Wild them...@gmail.com wrote: On 12/30/2010 03:34 PM, Ian Monroe wrote: On Thu, Dec 30, 2010 at 08:08, Michael Hertling mhertl...@online.de wrote: On 12/30/2010 11:33 AM, Ian Monroe wrote: To create my QyotoConfig.cmake I need to know the full path of a library so that I can set a variable like QYOTO_LIBRARY. This is pretty standard requirement right? Its what we're supposed to do in *Config.cmake's? Yes. So anyways, how do I that? The only target property that hasn't returned NOTFOUND is LOCATION, which unhelpfully returns the location of the library in the build directory. I could parse this to get the file name, and then append it to the library install location... but that seems like such a hack. Feels like I'm doing something wrong if I need to use a hack to do something standard. Usually, I'd have a template QyotoConfig.cmake.in which contains FIND_LIBRARY(QYOTO_LIBRARY qyoto PATHS @CMAKE_INSTALL_PREFIX@/lib NO_DEFAULT_PATH ) and is processed by CONFIGURE_FILE(). If the library is installed with INSTALL(TARGETS qyoto RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find the library right at the installation location but nowhere else, and the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll, are also handled correctly. I looked at install(EXPORT which could work, but it seems to include a lot more information then is needed. I just want to set a variable with the full path to a library. Nevertheless, the imported-targets approach, i.e. the combination of INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an appropriately set up config file, is much more powerful and should be preferred, IMO; see [1] for more information. BTW, as the export file defines the imported targets, its inclusion in the config file should possibly be protected in a suitable way to avoid fatal redefinitions. The context I'm coming from is that I'm developing stuff that is distributed by Linux distributions. The export file has information about what the target is dependent on, including full paths. That feels like a bad thing to me. What was true about dependencies when a package was being built on a build server might not be true later. If the paths on the build server don't match the ones on the destination system, then that distro is broken. Period. Here's what happens in the case of Debian/Ubuntu/...: - A minimal installation is unpacked from a tar-ball - The system chroots into the unpacked system - All dependencies are installed into the build environment - The package is built - The system exits the chroot, retrieves the package and discards the build environment This is to guarantee that the dependencies are set up correctly and that no strange interferences occur. Yes, I know how build systems work. But if some library that I depends on changes where it is installed, that very well might not matter at all to running my application. And mostly certainly not to building it. ...yet the EXPORT-created cmake would still refer to this old file. Maybe it doesn't really matter, just seems like bad practice to be referring to files that aren't yours in these cmake files that get installed. Ian ___ 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] providing library information, what's the cmake way
On Mon, Nov 22, 2010 at 10:37 PM, Michael Hertling mhertl...@online.de wrote: [snip] This seems like a common situation, so I'm wondering what the common solution is. 'hope that helps. Thanks, yes that helps a lot. I figured there must be some method like this. @Johannes Zarl: hijack away, I'm also interested in your questions. :) Ian ___ 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] providing library information, what's the cmake way
So with a library, the correct thing to do is to install your
FindLibrary.cmake into ${CMAKE_ROOT}/Modules and then dependent
projects would just do find_package(Library REQUIRED) correct?
I guess I'm thinking about how, in the situation where they don't have
the library installed, they would then just get a cmake error that it
can't find the FindLibrary.cmake. So that doesn't really seem right.
We're going from SVN to Git and splitting up a monolithic project
(kdebindings) into several separate projects (qtruby, korundum,
smoke...). I really don't want to have a copy of FindLibrary.cmake
(well really FindSmoke.cmake) in each project's repo.
This seems like a common situation, so I'm wondering what the common
solution is.
Thanks,
Ian
___
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] CTest w/ Coverage
On Sun, Apr 12, 2009 at 10:06 PM, Daniel Stonier d.ston...@gmail.com wrote: Ian, are you using ccache? No I just really didn't know where to start. Its not obvious from the wiki that just setting the correct gcc flags triggers a coverage test. :) I'll try out what Alex says tomorrow and edit the wiki accordingly. Ian ___ 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] Generating makefiles without installed CMake
2009/4/9 Ivan Chupahin gurin...@gmail.com: Hi! How can i generate the makefiles on a different systems, where no CMake is installed? It`s like a configure (autoconf utility). Install cmake? :) Ian ___ 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] copying files
On Wed, Apr 8, 2009 at 5:01 PM, Randy Heiland heil...@indiana.edu wrote: Is there a simple cmake procedure to copy files from a source dir to the installation dir? INSTALL works fine for this as well. Just read its API doc. Ian ___ 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] load CMakeCache.txt settings into new build directory?
On Mon, Apr 6, 2009 at 10:33 PM, Michael Jackson mike.jack...@bluequartz.net wrote: I _think_ the way to do this in your script would be to use either one of: -C initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. In the -C variant you would have a *.cmake file that has all the necessary entries in it that you want to set, or want the user to automatically have. I think you just use the normal cmake syntax: set(CMAKE_BUILD_TYPE Debug) In the -D variant you would need to pass in all the settings that you need on the command line: cmake -D CMAKE_BUILD_TYPE:STRING=Debug ../SourceDirectory But I don't really know what the users needs. Like for me I don't need to pass any options. Others might have had to tweak things to recognize a given library. I wonder if I could just run a findreplace regex on the CMakeCache.txt to change the build directory. Ian ___ 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] load CMakeCache.txt settings into new build directory?
On Tue, Apr 7, 2009 at 10:04 AM, John Drescher dresche...@gmail.com wrote: But I don't really know what the users needs. Like for me I don't need to pass any options. Others might have had to tweak things to recognize a given library. I wonder if I could just run a findreplace regex on the CMakeCache.txt to change the build directory. I am pretty sure I have done that manually with itk or vtk to avoid having to figure out what I set during a version upgrade. Yep turns out it works well. For some reason I didn't think it'd be that easy. Ian ___ 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] load CMakeCache.txt settings into new build directory?
I want to write a script that, in response to 'make distcheck', git clones the source repo into a new directory under the build directory, builds it and runs make test. The issue is that if the user had to tweak their cmake settings to get it to build thats not going to work, since the new build directory would need to be similarly tweaked. Is there a solution to this? Ian ___ 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] perennial question, how to setup environment for simple tests
On Thu, Apr 2, 2009 at 10:28 PM, Philip Lowman phi...@yhbt.com wrote: On Thu, Apr 2, 2009 at 3:19 PM, Ian Monroe i...@monroe.nu wrote: I've seen this question in the archives, but I was wondering if there's been any progress since I last saw it asked (1 year ago). I have some unit tests. I need to run a command or two and set some environmental variables before all the tests start. Does CMake have a solution for this yet? Are there any common practices to handle what I'm guessing is a pretty common thing? I notice that CTest would allow me to setup a test environment, but since it requires hardcoding the source and build directory it seems pretty inappropriate as a common-repo script used by multiple developers. Possibly the solution is to figure out how CTest can be used anyways. This feature has been implemented in CMake CVS for some time thanks to David Cole. If someone would commit the patch I sent in so it shows up in the documentation (attached to this bug) they could then close this bug. http://public.kitware.com/Bug/view.php?id=7885 also this duplicate bug as well. http://public.kitware.com/Bug/view.php?id=6391 Hey that's good to hear. I'll look forward to cmake 2.8 then. In the meantime I've just created a sh script and then execute that as the test. Not very portable, but then again I don't think these tests are either so its OK for me at the moment. :) Ian ___ 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] perennial question, how to setup environment for simple tests
I've seen this question in the archives, but I was wondering if there's been any progress since I last saw it asked (1 year ago). I have some unit tests. I need to run a command or two and set some environmental variables before all the tests start. Does CMake have a solution for this yet? Are there any common practices to handle what I'm guessing is a pretty common thing? I notice that CTest would allow me to setup a test environment, but since it requires hardcoding the source and build directory it seems pretty inappropriate as a common-repo script used by multiple developers. Possibly the solution is to figure out how CTest can be used anyways. Thanks, Ian Monroe ___ 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
