Re: [CMake] How to use verbose and debug output for CPack under VS
Is there an environment variable or a CMake/CPack variable which is must set? Thanks in advance Am 20.05.2012 um 20:10 schrieb noru...@me.com: > Hello, > > how can I configure a project for Visual Studio to use the "--verbose" and > the "--debug" options/command line parameters? > > Thanks in advance > > Best Regards > NoRulez > -- > > 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 -- 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] Windows 260 Char Limit Hit with CPack
Hi, On Mon, May 21, 2012 at 6:14 AM, David A. Alexander wrote: > > We are running CPack remotely through Jenkins [1] to end up running a > build/package process on a Windows 2008 Server machine and are seeing > errors during the install into the _CPack_Packages directory because file > paths exceeds the windows 260 character limit [2]. We have seen posts > about this problem [3] where the solution is to build outside of the source > directory, but this is not desirable for us because with Jenkins we want to > save build artifacts and look at the workspace remotely. For those not > familiar with Jenkins, the shortest build path starts with... > > C:\user_name\jenkins\workspace\project_name\configuration_name\machine_name > Hmm, at work our jenkins slaves running on windows would run the build from C:\jenkins-slave-user\workspace\\build, which is considerably shorter than what you have there. So it seems that this is customizable to a certain extent (I'm not an expert when it comes to jenkins on windows). I know thats not what you were looking for, but might be an easier to maintain change than patching CMake each time a new release is coming out. Andreas -- 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] Windows 260 Char Limit Hit with CPack
We are running CPack remotely through Jenkins [1] to end up running a build/package process on a Windows 2008 Server machine and are seeing errors during the install into the _CPack_Packages directory because file paths exceeds the windows 260 character limit [2]. We have seen posts about this problem [3] where the solution is to build outside of the source directory, but this is not desirable for us because with Jenkins we want to save build artifacts and look at the workspace remotely. For those not familiar with Jenkins, the shortest build path starts with... C:\user_name\jenkins\workspace\project_name\configuration_name\machine_name And any builds that are put under this base directory are then accessible through the web interface, which is very desirable for us. If we build out-of-place, then CPack works, but we don't see any of the build information through the Jenkins interface. We can make all of the names short, but we still run over the 260 character because the directories being copied during the install involve many subdirectories. This is due to third-party software that we can not control. What we would like is to be able to customize the destination directory for the CPack install (i.e. define the _CPack_Packages directory, so that can be in something like C:\tmp\_CPack_Package to stay under the 260 character limit). Is there any way to set where the _CPack_Packages directory ends up rather than having it under the build directory? We can build CMake itself and, if necessary, patch it to set this property. In other words, if we can make some change/customization in CMake where all of the _CPack_Packages directories land under C:\tmp or some other short directory, then that is an acceptable solution. We just need to know what code to change. Thanks, David A. Alexander Tech-X Corporation [1] Jenkins is https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins [2] For more info on the 260 character file path limit on windows see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/aa365247.aspx [3] Relevant Posts: http://www.cmake.org/pipermail/cmake/2011-January/041678.html http://cmake.3232098.n2.nabble.com/cpack-and-paths-too-long-td7480993.html -- 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] Finding include directories when importing targets exported via install(EXPORT ...)
On Tuesday 15 May 2012, Matthew LeRoy wrote:
> Hi again,
>
> I'm working on setting up install(...) commands for a shared library
> project (call it libA), and I'm using the install(EXPORT ...) signature as
> has been recommended to me previously to export the shared library target
> so I can import it in another CMake-based project (call it libB). So far
> things have been pretty straightforward, but I'm now trying to determine
> how to deal with the public header files for the project. So, two
> questions:
>
> 1. What's the preferred method for installing public headers? I've seen
> sparse documentation about a PUBLIC_HEADER target property, but the lack
> of information I can find about it via Google makes me wonder if it's not
> considered 'best practice'. Taking a look at the CMake list files for the
> LLVM project, they seem to be using multiple install(DIRECTORY ...)
> commands. I'm sure there are multiple ways to do this, so what's
> recommended?
set(INCLUDE_INSTALL_DIR include)
install(FILES a.h b.h. c.h. DESTINATION "${INCLUDE_INSTALL_DIR}" )
or using GNUInstallDirs.cmake:
include(GNUInstallDirs)
...
install(FILES DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}" )
> 2. How should libB find the location of the installed headers for libA?
> With Find* modules (of which I'm using a few, FindBoost being one), there
> is generally a LibName_INCLUDE_DIRs variable that gets set with the
> include path that I would add in libB's list file via
> include_directories(${LibName_INCLUDE_DIRS}). But, since I'm using
> exported/imported targets instead of a Find* module, there doesn't seem to
> be any built-in support for 'importing' the headers. I saw something in
> the release notes for a recent CMake version (2.8, I think?) about
> something called 'per-target INCLUDE_DIRECTORIES', which sounds promising,
> but couldn't find much more info about it.
This is related, but not yet ready for this purpose.
This is "just" that you can set per-target include dirs instead of using
include_directories()
which works per directory.
> Alright, I lied... a third somewhat-related question:
>
> 3) What's the general practice as far as where to install the .cmake file
> generated by the install(EXPORT ...) command? Should it go in the install
> location along with the built targets? It seems that the generated .cmake
> file is intended to replace Find* modules and prevent other projects from
> having to know the installed location of the exported library... but
> wouldn't putting the generated .cmake import file in the install location
> require dependent projects to know where the install location is in order
> to include the .cmake import file?
This is described in detail in the documentation to find_package().
Short version: put it into lib/cmake/$YourProject/
optionally with a version number:
lib/cmake/$YourProject-1.2.3/
CMake will look there for FooConfig.cmake.
I recommend to export the targets into a file named e.g. FooTargets.cmake, and
write FooConfig.cmake yourself, something like:
...
set(FOO_INCLUDE_DIRS ... )
include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake")
(CMAKE_CURRENT_LIST_DIR exists since cmake 2.8.3 I think)
Setting the include dirs here properly is not trivial.
The user expects it to be an absolute path.
Configuring an absolute path into this file at build time means the install
location of that package is fixed and cannot be changed later on.
To make this package "relocatable", i.e. so that the later user can decide
about the install location, I recommend to use CMakePackageConfigHelpers.cmake
coming with cmake 2.8.8, use the function configure_package_config_file().
If the documentation is unclear, let me know.
Alex
--
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 use verbose and debug output for CPack under VS
Hello, how can I configure a project for Visual Studio to use the "--verbose" and the "--debug" options/command line parameters? Thanks in advance Best Regards NoRulez -- 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] Packaging Best Practices for Linux
Hi, On Sun, May 20, 2012 at 07:57:52AM -0400, cmake-requ...@cmake.org wrote: > Date: Sun, 20 May 2012 13:46:49 +0200 > From: Alexander Neundorf > Subject: Re: [CMake] Packaging Best Practices for Linux > Can you put this information, how to build a LSB-compatible application using > cmake, somewhere in the cmake wiki ? > http://www.cmake.org/Wiki/CMake > > I guess this is a problem many cmake users have (maybe without knowing). Indeed, without knowing: while I knew about LSB tools of course, I remained unaware that they actually provide compiler wrappers, too, to try to provide reliable ABI compatibility. In the case of my app it still most certainly wouldn't be reliably successful (i.e. provide a universally runnable binary), e.g. for the reason that SuSE vs. RHEL wxWidgets packages - i.e. libraries not covered by core LSB specs AFAIK - chose to (/not) enable wx2.4 build compat config flag (and thus end up with incompatible vtable ABI issues). Andreas Mohr -- 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] copy dependant shared libs locally
On Sunday 20 May 2012, Daniel Krikun wrote: > I do that, but I want more. I want to trace third-parties. > In general, I would wonder why there is no such functionality available in > cmake, why is that there are all these helpful find* modules that find > headers, static libs etc., but not dlls. > Currently, we have to update the PATH variable, but it is tedious and > error-prone. Please keep replies on the list, so others can help too :-) Alex -- 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] Downgrade CMake
Hi! I want to downgrade from cmake 2.8-8 to 2.8-4 on OS X. Is there an easy way to do this? I tried to remove CMake from applications but the installer still says that a newer version already exists? Thanks! /Sason -- 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] Packaging Best Practices for Linux
2012/5/20 Alexander Neundorf : > On Thursday 17 May 2012, Craig Scott wrote: [...] > > Can you put this information, how to build a LSB-compatible application > using cmake, somewhere in the cmake wiki ? > > http://www.cmake.org/Wiki/CMake > > I guess this is a problem many cmake users have (maybe without knowing). Adding some references that may be used in the wiki (or found when searching the list): Main LSB site: http://www.linuxfoundation.org/collaborate/workgroups/lsb For installing LSB SDK from repo: https://wiki.linuxfoundation.org/en/RepositoryInfo Simple tuto: http://www.ludism.org/~rwhe/LSB/tutorial/tut.html I think there would be room for LSB support with some CMake scripts (at least) and may be some CPack actions as well (like running lsbappchk on each executable target etc...) -- Erk Le gouvernement représentatif 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: module and cmake
On Saturday 19 May 2012, Johannes Zarl wrote: > Hello Paul, > > I don't know about your specific find_package file for FFTW, but we do use > modules together with CMake, so I'll add my thoughts: > > As Eric already said, the modules command alters your environment. CMake > doesn't know about shell modules, but most find_package commands provide > some way to tell them about the location of a package by specifying an > environment variable (normally something like _ROOT or > _DIR). You'll have to look in the find-package script if this is > the case with your FindFFTW.cmake script. If it's not written in the > documentation on top of that file, search for "$ENV". > > If your FindFFTW3.cmake does not examine any environment variable, you > should fix it in your project (and file a bug with the original project, > if it's not your project). If that's not an option, it's probably best if > you just set whatever variable your findFFTW3.cmake script expects as a > clue as parameter to cmake (e.g. "cmake .. > -DFFTW3_INCLUDE_DIR=$FFTW3_ROOT/include"). > > So in summary, you should fix your module file to provide a suitable > variable pointing to your installation root, and you should also fix > poorly written FindXXX.cmake scripts circulating in the wild. Yes, either such a env. variable as pointed out here, or a modified CMAKE_PREFIX_PATH as mentioned in the other email. Alex -- 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] Why is Ninja generator disabled by default?
Hi Bill,thank you for that info.Indeed, the only major issue I can see is the problem with broken CMakeLists.txt files.http://public.kitware.com/Bug/view.php?id=13105But the solution is quit simple: cmake must add the missing include rules.ninja to the generated build.ninja file.You should know, many people do cross-compile on an UNIX like host (including macos), because it is mutch faster than Windows.With mingw or ppc toolchains build with busybox it is quiet easy (and fast)In these case, the ninja generator can double the build speed again!It is so fast, that the time-stamp resolution with secs is not enough, I have situations, where I need the nsec resolution too while building!I have provided a patch for ninja to used stat64() and a higher resolutions than secs.So for me nina works quiet well on OSX with gcc (tested with macports gcc V4.x, V4.6, V4.7 and mingw).The xcode IDE use a very old gcc, I would never use it!As IDE I use Eclipse and NetBeens, it works well with ninja ( with a makefile stub or direct)On Windows I use cygwin, mingw and gnu tools with Eclipse too, but I prefer a UNIX like development host.So please, there is no reason to disable the ninja generator by default.With regards,Clausp.s. try this script on an unix like system with this CMakeLists file to see what happens if the system is very fast.
bootstrap.sh
Description: Binary data
cmake_minimum_required(VERSION 2.8)
project(ninja_reconfigure_destroy_test CXX)
if(NOT CMAKE_GENERATOR MATCHES "Ninja")
message(FATAL_ERROR "CMAKE_GENERATOR is not set to Ninja!")
endif(NOT CMAKE_GENERATOR MATCHES "Ninja")
file(WRITE "test.cpp"
"int main()
{
return 0;
}")
set(file_list
test.cpp
#FIXME test_not_existing_file.cpp # <== TODO: UNCOMMENT THIS LINE after
first successfully build!
)
add_executable(test ${file_list})
On 18.05.2012, at 23:48, Bill Hoffman wrote:On 5/18/2012 5:37 PM, Claus Klein wrote:Hi,I downloaded the newest version 2.8 of cmake for MACOS and dit not foundthe new generator for ninja.So I downloaded the sources and build it myself.It seems to work fine and just 2 times faster than with make.Why is it disabled?See my post here:http://www.cmake.org/pipermail/cmake/2012-May/050304.htmlI assume you are on windows or Mac.So, if you are 2 times faster on windows it is because incremental builds are totally broken (although I suspect it will still be faster)... On the mac, you would be ok as long as the project does not create frameworks or app bundles.-Bill--Powered by www.kitware.comVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQFollow this link to subscribe/unsubscribe:http://www.cmake.org/mailman/listinfo/cmake--
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] target_link_libraries chain dynamic->static
On Thursday 17 May 2012, Petr Kmoch wrote: > Hi Anton, > > you should look into target property LINK_INTERFACE_LIBRARIES (and its > per-configuration variants) which controls "transitive linking." > target_link_libraries() also accepts LINK_INTERFACE_LIBRARIES as an > argument mode, which sets the property instead of linking. No, this is a different problem. Linking a shared library against static libraries does not have the effect that the object files of the static libs are included in the shared lib. But this is probably what Anton expected. So, since this does not happen, to resolve the functions when linking the executable, it also needs to link against the static libraries. So this is correct. "Convenience libraries" as they are called with autotools are not really supported with cmake. You have two options: 1) simply compile all source files directly into the shared library. They can be in different directories, no problem. 2) since cmake 2.8.8: instead of creating static libs, create a "object" libs: add_library(.. OBJECT ...). This basically avoids the need for recompiling the source files if the files are otherwise built multiple times (which may happen with solution 1) ). Alex -- 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] copy dependant shared libs locally
On Thursday 17 May 2012, Daniel Krikun wrote:
> Hello,
>
> I would like to trace shared library dependencies between targets (and also
> to external packages) and then copy required dll's to output bin directory
> (so that they are immediately available, without PATH editing) in the
> post-build.
> However, for debug configuration, I need to copy debug dll's (usually with
> 'd' suffix) and for release configuration - release dll's.
>
> I can copy files to run-time directory using add_custom_command, but how
> could I make a distinction for the release-debug files?
So you want to be able to run your executables directly from the buildtree,
right ?
To solve the problem for dlls which are built in your project, you can adjust
the directories where cmake creates executables and shared libs, so that they
are created in the same directory and the dlls will be found:
set(RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin" )
This should put both exes and dlls into one common directory.
Alex
--
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] Packaging Best Practices for Linux
On Thursday 17 May 2012, Craig Scott wrote: > > That was VERY informative. This is what I was afraid of. With Windows and > > OS > > X even though there are 3 or 4 versions if you build for the earliest one > (XP or 10.5) the binary has a really good chance of still running on the > latest (Win7 or Lion). With Linux and so many distributions I don't have > time to create that many different virtual machines to compile on each and > every one. I am a single developer. I think I am going to go the source > route and make sure that my software just compiles with the standard > packages from each of the distros (Qt 4, HDF5 1.8, Boost and Qwt). The > only issue might be Qwt as I still use Version 5 and I think there is a > newer version out that I doubt I am compatible with. All else fails I have > my own repo for Qwt that is public for anyone to pull from. > > >I very much want to support Linux in the best way possible. I was > >hoping > > for some thing easier but I guess this is just the way it is. > > > Don't give up just yet! There are other options which might meet your > needs. No-one appears yet to have mentioned the LSB (Linux Standards Base) > and it is designed to solve problems just like yours. Admittedly, it will > take a little bit of (one-time) work, but as someone who has done this > with production code at a previous employer, we found it was well worth > it. After getting things working, we only had to distribute a single > package to cover all linux distributions (yes, even Debian-based ones such > as Ubuntu). Can you put this information, how to build a LSB-compatible application using cmake, somewhere in the cmake wiki ? http://www.cmake.org/Wiki/CMake I guess this is a problem many cmake users have (maybe without knowing). Alex -- 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] Linking to libraries that depend on other libraries
On Thursday 17 May 2012, Andreas Pakulat wrote: > Hi > > Am Donnerstag, 17. Mai 2012 schrieb Petr Kmoch : > > Hi David, > > > > there's a target property LINK_INTERFACE_LIBRARIES (and > > per-configuration variants) which can be used for this purpose. > > Starting with 2.8.7, target_link_libraries() also accepts > > LINK_INTERFACE_LIBRARIES as a new argument mode, setting the property > > instead of linking. > > Actually using link_interface_libraries in target_link_libraries works > already in 2.6.4 I believe, since KDE uses that and requires that cmake > version at the moment. LINK_INTERFACE_LIBRARIES exists since cmake 2.6.2. http://www.cmake.org/Wiki/CMake_2.6.1_Docs http://www.cmake.org/Wiki/CMake_2.6.2_Docs http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix/Commands Alex -- 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] Packaging Best Practices for Linux
On Wednesday 16 May 2012, Michael Jackson wrote: ... > That was VERY informative. This is what I was afraid of. With Windows and > OS X even though there are 3 or 4 versions if you build for the earliest > one (XP or 10.5) the binary has a really good chance of still running on > the latest (Win7 or Lion). With Linux and so many distributions I don't > have time to create that many different virtual machines to compile on > each and every one. I am a single developer. I think I am going to go the > source route and make sure that my software just compiles with the > standard packages from each of the distros (Qt 4, HDF5 1.8, Boost and > Qwt). The only issue might be Qwt as I still use Version 5 and I think > there is a newer version out that I doubt I am compatible with. All else > fails I have my own repo for Qwt that is public for anyone to pull from. I > very much want to support Linux in the best way possible. I was hoping for > some thing easier but I guess this is just the way it is. Well, e.g. Kitware releases a binary cmake package for Linux for every release, so it is possible. You should use a relatively old distribution to build that binary package. Relying on Qt from the distro should be ok (... which means it kind of contradicts with "use an old distro"). Linking statically against Qwt and HDF5 would make things a bit easier. Otherwise you can link dynamically and set RPATH to $ORIGIN/../lib/ or something like this for your executable(s). The others are right that for a "first-class citizen" the package should get into the distro repository. Alex -- 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
