Re: [CMake] Determining appropriate setting for CMAKE_MINIMUM_REQUIRED
Hello Zac,
On 09/10/2015 23:27, Zac Bergquist wrote:
> Is there a particular tool or method that one should use to determine
> the appropriate setting for CMAKE_MINIMUM_REQUIRED? By appropriate, I
> mean the earliest version that encompasses all of the features used by
> the project.
This is what I used to do:
1) Check the compatibility matrix[1] (unfortunately it's useful only
until CMake 2.8.12). According to this, CMakePackageConfigHelpers was
introduced in CMake 2.8.8.
2) Check cmake documentation [2][3][4] for the versions that I'm
interested in (just change the version number in the url). For cmake <
3.0 the main page is cmake.html, for 3.0 and later it is index.html
3) Check the release notes[4] for 3.0 or later, changelog (usually
available on kitware blog) for previous versions
4) Check bug tracker[5], mailing lists archives, and git history
(usually as last resort) by searching for commit that introduced the
change that I'm interest in, and then running "git describe --contains
"
Then, even though I spent a lot of time searching, as soon as I commit
the changes, there is someone that complains that on some ancient CMake
version, the build is broken, because of some other feature or module
that I used without realizing that it was not supported.
Recently I switched to a trial and error approach using the
ExternalProject module. I have this "superproject" that I called (with
not much fantasy) "supercmake" and that downloads and builds all the
versions of CMake that I need to test. Then it tries to build my project
with all these versions.
It takes some time but after the first run, all the CMake versions are
already compiled (you could download and extract the binary versions, if
you want to improve it), but it is time that you can dedicate to
something else while the machine is building, instead of wasting time on it.
After building it, you are almost sure that the project will build with
all the cmake versions that you have to support, or you can use the
results to set CMAKE_MINIMUM_REQUIRED accordingly.
Attached is the CMakeLists.txt that I use, you just have to edit the
last ExternalProject_Add call, and eventually add or remove tags from
"CMAKE_TAGS".
I hope this is useful! :)
Cheers,
Daniele
[1]https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix
[2]https://cmake.org/cmake/help/v2.8.9/cmake.html
[3]https://cmake.org/cmake/help/v3.0/index.html
[4]https://cmake.org/cmake/help/git-master/release/index.html
[5]http://public.kitware.com/Bug/changelog_page.php?project_id=2
#=========
# Copyright 2014-2015 Daniele E. Domenichelli
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
cmake_minimum_required(VERSION 3.0)
project(supercmake NONE)
include(ExternalProject)
set(CMAKE_REPO "git://cmake.org/cmake.git")
set(CMAKE_URL_BASE "http://www.cmake.org/files";)
if(WIN32)
set(CMAKE_EXT "zip")
else()
set(CMAKE_EXT "tar.gz")
endif()
set(CMAKE_TAGS v2.8.9
v2.8.10.2
v2.8.11.2
v2.8.12.2
v3.0.2
v3.1.3
v3.2.3
v3.3.2
v3.4.0-rc1
master
next)
foreach(tag ${CMAKE_TAGS})
unset(url)
unset(version)
unset(prefix)
if(${tag} MATCHES "^v([0-9].[0-9])")
string(SUBSTRING ${tag} 1 -1 version)
set(url
${CMAKE_URL_BASE}/v${CMAKE_MATCH_1}/cmake-${version}.${CMAKE_EXT})
else()
set(version ${tag})
endif()
string(REGEX REPLACE "[\\.-]" "_" VERSION ${version})
if(url)
set(args URL ${url})
else()
set(args GIT_REPOSITORY ${CMAKE_REPO}
GIT_TAG ${tag})
endif()
set(prefix ${CMAKE_BINARY_DIR}/install/cmake-${version})
ExternalProject_Add(CMake_${VERSION}
CONFIGURE_COMMAND /configure --system-libs
--prefix=${prefix}
${args})
# This is where you build your project "FOO"
ExternalProject_Add(FOO_CMake_${VERSION}
GIT_REPOSITORY file:///path/to/your/local/clone/foo
GIT_TAG master
CMAKE_COMMAND ${prefix}/bin/cmake
CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX:PATH=${prefix}"
DEPENDS CMake_${VERSION})
endforeach()
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.
Re: [CMake] CMAKE_CFG_INTDIR
On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> in configure time, instead of build time?
>
> If there is not, is it safe to assume that the name of the directory is
> equal to the name of the current configuration?
Bump?
What I would like to do is to be able to change
CMAKE_RUNTIME_OUTPUT_DIRECTORY (and similar variables) with something
that contains the current configuration directory, i.e.
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY .../${CMAKE_CFG_INTDIR}/...)
but unfortunately CMAKE_CFG_INTDIR causes an error when targets are
installed.
I was able to have something that works as I expect by doing this:
foreach(config ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER ${config} CONFIG)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONFIG} .../${config}/...)
endforeach()
But I was wondering if it is safe to assume that the current directory
is always "${config}" or if it might be different.
Cheers,
Daniele
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] CMAKE_CFG_INTDIR
Hello, Is there an alternative variable for CMAKE_CFG_INTDIR that can be used in configure time, instead of build time? If there is not, is it safe to assume that the name of the directory is equal to the name of the current configuration? Cheers, Daniele -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Git Doesn't to Pull with ExternalProject_Add
Hello Constantine,
On 14/11/13 12:03, Constantine Zakkaroff wrote:
> Now, setting ${proj}_GIT_TAG to "origin/master" seems to improve things.
> I got this output:
If you plan to use the external project repository for development, then
being in detached state is not good. Also every time that the update
step is executed I believe that CMake will checkout the latest
origin/master that you fetched, not the current one, because the fetch
step is executed only if necessary (i.e. if the name origin/master was
not found). And I believe that your current commit(s) will be just
dropped in favour of the hash of origin/master (they will still be in
your repository and in your reflog, but as "dangling commits" and
therefore might be deleted.
And basically the pull is not executed.
Perhaps we need a "GIT_BRANCH" arguments to handle this in a different
way compared to "GIT_TAG", what do you think?
Also note that there is another important bug that makes developing in
git clones handled by ExternalProject complicate, see
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7840
I have a partial patch for that but I couldn't find the time to finish
it yet.
Cheers,
Daniele
--
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] Git Doesn't to Pull with ExternalProject_Add
Hello Constantine,
I'm investigating the same issue right in this moment...
On 13/11/13 10:19, Constantine Zakkaroff wrote:
> I have a SuperBuild project (using CMake 2.8.12 on Windows Vista x64)
> depending on some other project cloned from a git repository. However
> I've noticed the cloner repository doesn't get updated when I rebuild
> the project.
>
> Is it right to expect the repository to be updated automatically? Or
> does it need to be done manually?
How do you set ${proj}_GIT_TAG? If it a tag or a commit hash it should
work, therefore if you change it in your superbuild, your repository
should be updated.
Unfortunately it doesn't work for branches. Therefore if you set it to
"master" it will work for the clone, but it won't work for the updates,
because the branch "master" is your local branch not the remote one
("origin/master")
Perhaps this should be fixed somehow, either the documentation of the
module to explicitly state this, or the module itself to pull from the
remote branch if GIT_TAG is a branch.
Cheers,
Daniele
--
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] INTERFACE_COMPILE_DEFINITIONS on imported targets
Hello all, Is there a way to set the property INTERFACE_COMPILE_DEFINITIONS in a different way for different configurations on imported targets? From the help it seem to exist COMPILE_DEFINITIONS_, but I don't see an equivalent for the "INTERFACE" version... Cheers, Daniele -- 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] [PATCH] FindGTK2: Move check for pangocairo in gtk module
Dear CMake developers,
FindGTK2 searches for pangocairo only when looking for the gtkmm module,
but afaik it is possible to use the pangocairo library without gtkmm.
Therefore I believe that it should search the library in the gtk module.
Attached is a patch that fixes this issue.
Regards,
Daniele
>From 5e93a9fc0671e62cf95e8a28c61e4b6ec8eca129 Mon Sep 17 00:00:00 2001
From: "Daniele E. Domenichelli"
Date: Sat, 15 Jun 2013 00:53:56 +0200
Subject: [PATCH] FindGTK2: Move check for pangocairo in gtk module
---
Modules/FindGTK2.cmake |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Modules/FindGTK2.cmake b/Modules/FindGTK2.cmake
index 06cf962..7d5a5c4 100644
--- a/Modules/FindGTK2.cmake
+++ b/Modules/FindGTK2.cmake
@@ -460,6 +460,8 @@ foreach(_GTK2_component ${GTK2_FIND_COMPONENTS})
_GTK2_FIND_INCLUDE_DIR(GTK2_PANGO_INCLUDE_DIR pango/pango.h)
_GTK2_FIND_LIBRARY(GTK2_PANGO_LIBRARY pango false true)
+_GTK2_FIND_LIBRARY(GTK2_PANGOCAIRO_LIBRARY pangocairo true true)
+
_GTK2_FIND_INCLUDE_DIR(GTK2_GDK_PIXBUF_INCLUDE_DIR gdk-pixbuf/gdk-pixbuf.h)
_GTK2_FIND_LIBRARY(GTK2_GDK_PIXBUF_LIBRARY gdk_pixbuf false true)
@@ -489,8 +491,6 @@ foreach(_GTK2_component ${GTK2_FIND_COMPONENTS})
_GTK2_FIND_INCLUDE_DIR(GTK2_PANGOMMCONFIG_INCLUDE_DIR pangommconfig.h)
_GTK2_FIND_LIBRARY(GTK2_PANGOMM_LIBRARY pangomm true true)
-_GTK2_FIND_LIBRARY(GTK2_PANGOCAIRO_LIBRARY pangocairo true true)
-
_GTK2_FIND_INCLUDE_DIR(GTK2_CAIROMM_INCLUDE_DIR cairomm/cairomm.h)
_GTK2_FIND_INCLUDE_DIR(GTK2_CAIROMMCONFIG_INCLUDE_DIR cairommconfig.h)
_GTK2_FIND_LIBRARY(GTK2_CAIROMM_LIBRARY cairomm true true)
--
1.7.10.4
--
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] "make superclean" target? (i.e. clear *everything*)
On 04/04/13 15:34, Eric Noulard wrote: > CMake cannot currently do that and it does not seem wise > to ask for that feature. > You may search the mailing list for this discussion topic and you'll find > many answers. > > The only [reasonable] option is to do out-of-source build, > then you know for sure that you can throw away the build tree. > > Safely avoiding accidental in-source build is a feature request: > http://public.kitware.com/Bug/view.php?id=6672 That would work even better for me... > Another option which is unrelated to CMake in order to clean-up a source > tree > is to use a VCS which may be able to remove any non versioned file easily. > (see e.g. git clean) That works as well, but you need to pay really good attention if you have some unversioned files in your source tree (for example because you didn't commit them yet) Cheers, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] "make superclean" target? (i.e. clear *everything*)
Hello, On 04/04/13 11:40, Ansis Māliņš wrote: >> Is it possible to ask CMake to make another "make clean" target >> that clears *all* the CMake generated files including the cache? I >> am a bit annoyed that the only way to clear everything is to >> basically run "rm -rf *". > > What would be the benefit of such a command besides syntax? I also find that such a command would be useful. It could be something like the "make maintainer-clean" target generated by autotools. One benefit is that it would allow to easily remove all cmake files when you wrongly run cmake in the source directory instead of in the build one. Cheers, 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeModules repository at GitHub?
Hello, On 28/03/13 22:28, David Cole wrote: > I, too, live in the real world, in addition to having my theories about > it... :-) > > And, for what it's worth, I'd rather add a project config file to any > project out there that would accept code contributions from me than add > yet another find module into CMake. > > Obviously, there will be cases where that is simply not possible for > one reason or another. But it's still the preferred mechanism for > hooking into CMake's find_package when it is possible. > > And when you have to resort to a find module, it should definitely live > in CMake if it's generally useful for more than just your own use... One of the projects I work on, is currently supporting Debian Squeeze, and will have to support Debian Wheezy for at least until the next release (2015?), any software that doesn't have a config file yet, won't have it probably for the whole lifetime of this release; moreover CMake will probably stay at version 2.8.9. So from my point of view, it's nice to have new projects releasing config files for CMake and/or more FindXXX files in newer versions of CMake, but even if in the long term is the way to go, it is simply not useful in my case. Even though libraries gets the cmake config files, in order to support older versions of that library, we will still need a Find module. Moreover, I don't the "imported targets" unless the NAMESPACE option is used, and I didn't see many packages using it yet. Also modules often get fixes and tweaks in newer versions of CMake, sometimes they are still compatible with previous versions and could be used, sometimes they are not. Referring to [1] every time you have to check if a version of CMake supports one or has some bug fixed is sometimes frustrating (especially when the answer is no). I'd really appreciate an extra repository with find files that are guaranteed to work on different versions of cmake (i.e. having several branches, of which one is for CMake 2.8.9 that doesn't use any new feature from 2.8.10). If that was some kind of "official" package, I would be even happier. It would be a lot easier just to update that script package, or just take the required files and copy them in your project, rather than require newer version of cmake and/or of external software. Cheers, Daniele [1]http://www.itk.org/Wiki/CMake_Version_Compatibility_Matrix/StandardCMakeModules -- 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] FindXXX capitalization recommendation for new modules
On 31/08/12 17:59, David Cole wrote: The best thing is to not write new find modules... Rather, have the project itself provide a project/package config file that CMake's find_package can find without a find module. Do you have to write a new find module? What package is it for? Actually I don't have to write a new one, but I'm trying to clean up the mess with the Find modules used in Yarp [1] (You can find the modules here[2]). Our idea is to clean them following the guidelines, remove the duplicates and eventually contribute and maintain them upstream... We don't have many compatibility issues, so we are trying to do it properly... Cheers, Daniele [1]http://eris.liralab.it/yarp/ [2]http://yarp0.svn.sourceforge.net/viewvc/yarp0/trunk/yarp2/conf/ -- 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] FindXXX capitalization recommendation for new modules
Hello, I tried to find this out, but I cannot find a clear answer to this question: what are the capitalization recommendation when writing a _new_ module? Let's say the library name is "X" The module file should be FindX.cmake or FindX.cmake? The variables - X_FOUND or X_FOUND? - X_INCLUDE_DIRS or X_INCLUDE_DIRS? Thanks 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL TARGET with no target to compile
On Thursday 29 January 2009, Alexander Neundorf wrote:
> On Thursday 29 January 2009, Daniele E. Domenichelli wrote:
>> I have a small template library in c++ composed by ".h" files only and I
>> want to use cmake to configure, find dependencies and install the
>> library (compiling is not needed).
>>
>> This template library is in a bigger package with some other libraries
>> that I install using "INSTALL TARGET" signature.
>>
>> I know I could use "INSTALL FILES", but I would like to use the same
>> syntax ("INSTALL TARGET") for the first library, so I tried creating a
>> new target, but with no results... Is there a way to do it?
>
> No. If you just have to install a set of files, use install(FILES).
> If you didn't create a target using add_executable() or add_library(), you
> can't use install(TARGETS)
> Do you have some specific problem with install(FILES ) ?
Hi, Thanks for the answer.
No, I don't have any specific problem with install(FILES), my problem
was just because I'm installing all the other sublibrary of my project
using install(TARGETS) and I was guessing if I could use the same syntax
for all of them for easier maintenance...
Regards,
Daniele
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] INSTALL TARGET with no target to compile
I have a small template library in c++ composed by ".h" files only and I
want to use cmake to configure, find dependencies and install the
library (compiling is not needed).
This template library is in a bigger package with some other libraries
that I install using "INSTALL TARGET" signature.
I know I could use "INSTALL FILES", but I would like to use the same
syntax ("INSTALL TARGET") for the first library, so I tried creating a
new target, but with no results... Is there a way to do it?
Regards,
Daniele
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
