[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
Re: [CMake] CMAKE_LANG_OUTPUT_EXTENSION
On 04.09.2013 20:42, Michael Wild wrote:
Dear all
no matter when I try to set CMAKE_{C,CXX}_OUTPUT_EXTENSION, on my Linux
box using the GNU Makefiles generator the resulting object files always
have a .o extension. I tried setting it in the cache, before and after
the project() call. Nothing helps.
Is this a known issue? I tried trawling the archives, but only found
references to IDE generators ignoring this setting.
Thanks for any help
Michael
Seems like commit 422dc631b by Alex kind of broke the user's ability to specify
CMAKE_LANG_OUTPUT_NAME by unconditionally setting it to .o on UNIX and .obj
otherwise. The only solution I can see is to provide/override platform+compiler
specific files which get loaded by CMakeLANGInformation.cmake like this:
---8
cmake_minimum_required(VERSION 2.8)
project(output_extension NONE)
# create fake system- and compiler specific file
file(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/cmake/Platform)
foreach(id GNU HP Intel MIPSpro PathScale PGI SunPro VisualAge XL)
foreach(l C CXX)
file(WRITE
${PROJECT_BINARY_DIR}/cmake/Platform/${CMAKE_SYSTEM_NAME}-${id}-${l}.cmake
# SET EXTENSION HERE =
set(CMAKE_${l}_OUTPUT_EXTENSION .MyFancyExtension)\n
include(\${CMAKE_ROOT}/Modules/Platform/\${CMAKE_SYSTEM_NAME}-\${CMAKE_${l}_COMPILER_ID}-${l}.cmake\\n
OPTIONAL RESULT_VARIABLE _INCLUDED_FILE)\n
if(NOT _INCLUDED_FILE)\n
INCLUDE(\${CMAKE_ROOT}/Modules/Platform/\${CMAKE_SYSTEM_NAME}-\${CMAKE_BASE_NAME}.cmake\\n
OPTIONAL RESULT_VARIABLE _INCLUDED_FILE)\n
endif()\n
if(NOT _INCLUDED_FILE)\n
INCLUDE(\${CMAKE_ROOT}/Modules/Platform/\${CMAKE_SYSTEM_NAME}.cmake\
OPTIONAL)\n
endif()\n
)
endforeach()
endforeach()
list(INSERT CMAKE_MODULE_PATH 0 ${PROJECT_BINARY_DIR}/cmake)
cmake_policy(PUSH)
cmake_policy(SET CMP0017 OLD)
enable_language(C)
enable_language(CXX)
cmake_policy(POP)
---8
Michael
--
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] Build Library from Thrift generated files
2013/9/4 Pascal Bach pasci.b...@gmail.com: Hello Eric Unknown source file name is just painful. Can't the thrift generator tell you the name of the files he will generate? Something like: thrift --generated-file-list Service.thrift or may be you can teach him the name of the flie you want? Currently there is no way toget just a list of the generated output file. One idea that I had was to just run the process once to get a list of the generated output files and then throw the files away. If I wrap this in a function it would be similar to the generated-file-list. But it seems like a waste to me. Because the output of the generator is dependent on the content of the file it is not possible to specify an output file, only an output directory. How wouldn't the output depend on the content of the input :-]... just kidding. The not predictable output is is a biased point of view :-) Even if thrift needs to generate several classes, functions whatever nothing prevent the tool of putting that in 2 (possibly) big files, like: Services.thrift -- Services.hh Services.cpp I do use a (home made) source generator which does just that. Generating 1 file per class is a convention not an obligation. At least in C, C++ and Python. Moroever in the end you build a library which contains all the generated code so what the point of having dozens of files? -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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] find_package
Using Latest version of CMake on Windows 7 and Redhat 6
Running the below code on both platforms produce slightly different content in
QT_LIBRARIES.
FIND_PACKAGE(Qt4 4.7.1 COMPONENTS QtCore QtGui)
IF (QT4_FOUND)
MESSAGE(STATUS QT_LIBRARIES: ${QT_LIBRARIES}
ENDIF()
On Windows I get;
Optimized;c:/tools/qt/lib/QtCore4.dll;debug;c:/tools/qt/lib/QtCored4.dll;
Optimized;c:/tools/qt/lib/QtGui4.dll;debug;c:/tools/qt/lib/QtGuid4.dll;
On Redhat I get;
/tools/qt/lib/libQtCore.so;/tools/qt/lib/libQtGui.so
The Redhat version is missing the keywords Optimzed and Debug.
Reading the spec is appears the keywords are optional, is that correct?
So when no keyword is specified, then the library can be used with all
configurations?
--
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] Version Check
While searching for a version number comparison, I found a few custom solutions[1][2], but nothing official. Is there a canonical way of saying: IF (LIBXML2_VERSION GREATER_EQUAL 2.8.0) do_something... END If not, which is the custom solution I should use? Thanks! --renato [1] http://www.cmake.org/Wiki/CMakeCompareVersionStrings [2] http://article.gmane.org/gmane.comp.programming.tools.cmake.user/8533/match=version+comparison -- 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] Version Check
2013/9/5 Renato Golin renato.go...@linaro.org: While searching for a version number comparison, I found a few custom solutions[1][2], but nothing official. Is there a canonical way of saying: IF (LIBXML2_VERSION GREATER_EQUAL 2.8.0) do_something... END If not, which is the custom solution I should use? Yes there is the VERSION_ comparison operator: see cmake --help-command if -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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] Version Check
Thanks! That answers my question. ;) --renato On 5 September 2013 10:26, Eric Noulard eric.noul...@gmail.com wrote: 2013/9/5 Renato Golin renato.go...@linaro.org: While searching for a version number comparison, I found a few custom solutions[1][2], but nothing official. Is there a canonical way of saying: IF (LIBXML2_VERSION GREATER_EQUAL 2.8.0) do_something... END If not, which is the custom solution I should use? Yes there is the VERSION_ comparison operator: see cmake --help-command if -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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] Version Check
On 5 September 2013 10:21, Renato Golin renato.go...@linaro.org wrote: While searching for a version number comparison, I found a few custom solutions[1][2], but nothing official. Is there a canonical way of saying: IF (LIBXML2_VERSION GREATER_EQUAL 2.8.0) do_something... END If not, which is the custom solution I should use? Thanks! --renato [1] http://www.cmake.org/Wiki/CMakeCompareVersionStrings [2] http://article.gmane.org/gmane.comp.programming.tools.cmake.user/8533/match=version+comparison Hit the official manual, Luke! ;-) http://cmake.org/cmake/help/v2.8.11/cmake.html#command:if Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Participation in this whole process is a form of torture ~~ Szalony -- 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] Build Library from Thrift generated files
Unknown source file name is just painful. Can't the thrift generator tell you the name of the files he will generate? Something like: thrift --generated-file-list Service.thrift How wouldn't the output depend on the content of the input :-]... just kidding. The not predictable output is is a biased point of view :-) Even if thrift needs to generate several classes, functions whatever nothing prevent the tool of putting that in 2 (possibly) big files, like: Services.thrift -- Services.hh Services.cpp I do use a (home made) source generator which does just that. Generating 1 file per class is a convention not an obligation. At least in C, C++ and Python. I discussed you proposal with one of the thrift maintainers. He will discuss the idea of a generated-list option and maybe it will be added. In the meantime I will go with the files pre generated and I treat them as all the other source files. This means the developer has to trigger the regeneration process manually. For the moment this is acceptable for me. Thanks for your help. Regards Pascal -- 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] Build Library from Thrift generated files
2013/9/5 Pascal Bach pasci.b...@gmail.com: Unknown source file name is just painful. Can't the thrift generator tell you the name of the files he will generate? Something like: thrift --generated-file-list Service.thrift How wouldn't the output depend on the content of the input :-]... just kidding. The not predictable output is is a biased point of view :-) Even if thrift needs to generate several classes, functions whatever nothing prevent the tool of putting that in 2 (possibly) big files, like: Services.thrift -- Services.hh Services.cpp I do use a (home made) source generator which does just that. Generating 1 file per class is a convention not an obligation. At least in C, C++ and Python. I discussed you proposal with one of the thrift maintainers. He will discuss the idea of a generated-list option and maybe it will be added. I do not use thrift but they seem open minded, good to know. In the meantime I will go with the files pre generated and I treat them as all the other source files. This means the developer has to trigger the regeneration process manually. For the moment this is acceptable for me. I suggest you keep an add_custom_target for that purpose. I used that very often for gengetopt generated files. I put the generated files in the VCS and I have a custom target which may be invoked like: make GenCmdlineSrc so that the developer do not have to remember how to launch gengetopt (or any other kind of source file generator). Since add_custom_target has no specified output and no other target depends on it is NEVER launched unless you ask to build it explicitely. Thanks for your help. You are welcome. -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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] find_package(mpi) language specification
Hello, My C++ code only uses the MPI C library. 1. Is there a way to tell find_package(MPI) to only look for the C version? 2. If not, can FindMPI.cmake be changed to support this (just like with Boost you can specify only the components you need) 3. If not, can that warning message Could NOT find MPI_CXX missing: MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH be suppressed? It is *extremely* confusing to users. More info: The language-specific detection for MPI that was added a few versions ago has been a huge help in avoiding linking with the deprecated MPI C++ library. I still have a problem, and that is find_package(MPI) still attempts to find the MPI C++ library. When it is not found, which is more often than not the case on the various HPC systems this code runs on, the warning Could NOT find MPI_CXX missing: MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH is issued. I do not want CMake to even try to detect the C++ version of MPI, and this has been a major source of confusion for users of this code, since they think that something has gone wrong and report it to me. In response to this, I added the following clarification, but despite this, users remain confused. if(NOT MPI_CXX_FOUND) message(STATUS == MPI_CXX_* IS NOT REQUIRED) message(STATUS == IGNORE ANY WARNING REGARDING MPI_CXX_*) end Thanks, Andrew Corrigan -- 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] Configuring CPack to Build Packages My Way
I want CPack to build packages that result in installing files in a particular structure, regardless of whether I'm using TGZ, ZIP, NSIS, RPM, etc. I'm having trouble making this work and need help. Let me make things concrete. I have successfully configured CMake to install platform-specific files as follows: directories/leading/to/my/installation/files/ platform1/ product/ version/ files (more subdirectories, but irrelevant) platform2/ product/ version/ files (more subdirectories, but irrelevant) etc. I want to build a ZIP or TGZ package of the platform directories above, change to some desired directory, decompress the .tgz or .zip file, and wind up with the above structure in the current directory. That is, nothing from directories/leading/to/my/installation/files should appear in the current directory. Likewise, I want an NSIS installer or RPM that will create that directory structure in either a default location from my CMakeLists.txt or in a directory selected by the user during installation (via the GUI for NSIS or --prefix for rpm). What must I do to effect this? _ Rob Stewart Software Engineer Dev Tools Components Susquehanna International Group, LLP IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -- 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] Problem on an external library depending on an internal one
I have this same question. There doesn't seem to be a way to have these imported target see other targets. I can pull the full path out for this target, but it seems less elegant. On Thu, Dec 22, 2011 at 11:08 AM, Marco Corvo marco.co...@pd.infn.itwrote: Hi all, I have a big project which can be used in two ways: either the user checks out all the packages and makes a big make or he checks out only a subset and build them linking against a given release, which is installed somewhere else on his machine. In this last option the libraries installed somewhere are trated as external dependencies by the working packages. The problem I have comes out when I have a transitive dependency. To make an example, I check out two packages: package A, which builds a static library and a binary and depends on an external library B, and a package C. The cmake code to make A know where to find libB.a is the following: add_library(B STATIC IMPORTED) set_target_properties(B PROPERTIES IMPORTED_LOCATION /path/to/external/lib/libB.a IMPORTED_LINK_INTERFACE_**LIBRARIES C D ) which is read inside my CMakeLists.txt with: import(MyFile.cmake) add_library(A foo.cc) add_executable(bar bar.cc) target_link_libraries(bar A B) Here's the point. My library B depends on C, which I checked out with A and so is kind of local to my build, in fact I have: add_directory(A) add_directory(C) in my main CMakeLists.txt, but when I build the packages I always get: No rule to make target `../../lib/libC.a', needed by `../../bin/bar'. Stop. Looking into the link.txt file generated by cmake, I see that the dependencies are correct, that is the command is: g++ -o bar ../../lib/libA.a /path/to/external/lib/libB.a ../../lib/libC.a /path/to/external/lib/libD.a So this is not a problem of how I declare my dependencies among packages, rather something related to the way cmake deals with the targets. What sounds strange to me is that package C is perfectly known to cmake, as I put add_directory(C) to my CMakeLists.txt. In fact libC.a is built, but always *after* bar, like cmake were not aware that C, on which bar depends, must be built before it. I suspect that cmake thinks that, since B is external, it's up to the user to provide a rule to force the build of dependencies. Put it another way: if you have packages A and C locally and B is an external but depends on C, then cmake has no means to write the target libC.a that triggers the build of C before linking A with B. Is there a way, if any, to instruct cmake to write the targets so that the dependencies chain is preserved and if an external depends on an internal, the internal is built before the link stage? Thanks in advance. Marco -- Marco Corvo SuperB Experiment CNRS - Orsay c/o INFN Padova -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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] find_package(mpi) language specification
You can pass the QUIET parameter to find_package... that'll at least shut it up. Perhaps easiest in your case. On 2013-05-09, at 18:22:25 , Andrew Corrigan wrote: Hello, My C++ code only uses the MPI C library. 1. Is there a way to tell find_package(MPI) to only look for the C version? 2. If not, can FindMPI.cmake be changed to support this (just like with Boost you can specify only the components you need) 3. If not, can that warning message Could NOT find MPI_CXX missing: MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH be suppressed? It is *extremely* confusing to users. More info: The language-specific detection for MPI that was added a few versions ago has been a huge help in avoiding linking with the deprecated MPI C++ library. I still have a problem, and that is find_package(MPI) still attempts to find the MPI C++ library. When it is not found, which is more often than not the case on the various HPC systems this code runs on, the warning Could NOT find MPI_CXX missing: MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH is issued. I do not want CMake to even try to detect the C++ version of MPI, and this has been a major source of confusion for users of this code, since they think that something has gone wrong and report it to me. In response to this, I added the following clarification, but despite this, users remain confused. if(NOT MPI_CXX_FOUND) message(STATUS == MPI_CXX_* IS NOT REQUIRED) message(STATUS == IGNORE ANY WARNING REGARDING MPI_CXX_*) end Thanks, Andrew Corrigan -- 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 -- 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] Xcode iOS build
Hi,I'm trying to use CMake to configure Xcode to build for iOS. So far, i've managed to do all the necessary configuration and the compilation is successful. Unfortunately, I can't launch on the simulator, when i launch, Xcode just stops running the app, and the simulator is crashed, I then have to manually delete the app from the finder so the simulator can launch again.I thought it might be a problem of the path to which i compile (all variable CMAKE_BINARY_TYPE_OUTPUT_DIR are set in my CMakeLists). So I removed all the command regarding the output path, the issue then became that Xcode was trying to find the static libs to link in OUTPUT_DIR/Debug and Xcode generates in OUTPUT_DIR/Debug-iphoneos. I tried to fix this particular issue, without success so far. Any idea about what I should do ?Ideally, I'd like to be able to compile with the first method mentioned, since it's the one that seems to be closer to be completed.Does someone have an idea of where the problem comes from ?Thanks--Pierre AufrèreDéveloppeur66 rue Marceau93100 Montreuil+33 1.48.97.95.93 -- 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] find_package(mpi) language specification
Thank you. QUIET is definitely an improvement, and I can live with that. However, it would still be nice to be able to reduce clutter and remove MPI_CXX_* and MPI_LIBRARY, MPI_EXTRA_LIBRARY from the CMake cache, to avoid overwhelming or confusing users. On Sep 5, 2013, at 1:29 PM, Nick Overdijk n...@astrant.net wrote: You can pass the QUIET parameter to find_package... that'll at least shut it up. Perhaps easiest in your case. On 2013-05-09, at 18:22:25 , Andrew Corrigan wrote: Hello, My C++ code only uses the MPI C library. 1. Is there a way to tell find_package(MPI) to only look for the C version? 2. If not, can FindMPI.cmake be changed to support this (just like with Boost you can specify only the components you need) 3. If not, can that warning message Could NOT find MPI_CXX missing: MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH be suppressed? It is *extremely* confusing to users. More info: The language-specific detection for MPI that was added a few versions ago has been a huge help in avoiding linking with the deprecated MPI C++ library. I still have a problem, and that is find_package(MPI) still attempts to find the MPI C++ library. When it is not found, which is more often than not the case on the various HPC systems this code runs on, the warning Could NOT find MPI_CXX missing: MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH is issued. I do not want CMake to even try to detect the C++ version of MPI, and this has been a major source of confusion for users of this code, since they think that something has gone wrong and report it to me. In response to this, I added the following clarification, but despite this, users remain confused. if(NOT MPI_CXX_FOUND) message(STATUS == MPI_CXX_* IS NOT REQUIRED) message(STATUS == IGNORE ANY WARNING REGARDING MPI_CXX_*) end Thanks, Andrew Corrigan -- 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 -- 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] Confusion with include() relativity
I have an interesting structure for my code build scripts:
root/
source/
CMakeLists.txt
build/
CMakeLists.txt
cmake/
common.cmake
My root CMakeLists.txt is actually in 'root/source/build, and my
common scripts are in root/cmake.
From my root CMakeLists.txt file, I do this:
get_filename_component( BUILD_PRODUCT_ROOT ${CMAKE_SOURCE_DIR}/../.. ABSOLUTE )
set( CMAKE_MODULE_PATH
${BUILD_PRODUCT_ROOT}/cmake
${BUILD_PRODUCT_ROOT}/cmake/find
)
add_subdirectory( ${BUILD_PRODUCT_ROOT}/source source )
Note that the script root/source/CMakeLists.txt is where I begin
defining targets, and it never steps into build (to avoid infinite
recursion).
Later on (still in the root script) I do:
include( common )
This includes root/cmake/common.cmake as expected, but inside
common.cmake when I try to include a file (not a module) relative to
common.cmake, it says it can't find it. Example:
include( foo/bar/stuff.cmake )
The absolute path for this would be:
root/cmake/foo/bar/stuff.cmake
Naturally I assume that when including a FILE (not a module!) that it
is relative to the CMAKE_CURRENT_LIST_DIR, which in this case
correctly displays as root/cmake.
Can anyone explain why I can't include files from common.cmake? Thanks
in advance.
--
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] Confusion with include() relativity
I am attaching a sample that reproduces the issue. I'm using CMake
version 2.8.11.2. To reproduce this, just run the 'generate.bat' batch
file from its current directory (WINDOWS ONLY). I have set it up to
generate for Visual Studio 2008, but you can edit the batch file to
change this.
Password to the archive is: cmake
On Thu, Sep 5, 2013 at 5:26 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
I have an interesting structure for my code build scripts:
root/
source/
CMakeLists.txt
build/
CMakeLists.txt
cmake/
common.cmake
My root CMakeLists.txt is actually in 'root/source/build, and my
common scripts are in root/cmake.
From my root CMakeLists.txt file, I do this:
get_filename_component( BUILD_PRODUCT_ROOT ${CMAKE_SOURCE_DIR}/../.. ABSOLUTE
)
set( CMAKE_MODULE_PATH
${BUILD_PRODUCT_ROOT}/cmake
${BUILD_PRODUCT_ROOT}/cmake/find
)
add_subdirectory( ${BUILD_PRODUCT_ROOT}/source source )
Note that the script root/source/CMakeLists.txt is where I begin
defining targets, and it never steps into build (to avoid infinite
recursion).
Later on (still in the root script) I do:
include( common )
This includes root/cmake/common.cmake as expected, but inside
common.cmake when I try to include a file (not a module) relative to
common.cmake, it says it can't find it. Example:
include( foo/bar/stuff.cmake )
The absolute path for this would be:
root/cmake/foo/bar/stuff.cmake
Naturally I assume that when including a FILE (not a module!) that it
is relative to the CMAKE_CURRENT_LIST_DIR, which in this case
correctly displays as root/cmake.
Can anyone explain why I can't include files from common.cmake? Thanks
in advance.
cmake-test.7z
Description: Binary data
--
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-commits] CMake branch, master, updated. v2.8.11.2-823-g8ff2b55
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 8ff2b5548c63aadea787b7e2a110100995c7ae56 (commit) from e5f6bf587d64518a79a33e8f6a141b6267849d3d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ff2b5548c63aadea787b7e2a110100995c7ae56 commit 8ff2b5548c63aadea787b7e2a110100995c7ae56 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Sep 6 00:01:05 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Sep 6 00:01:05 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index cfa24ef..1d40099 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 11) -set(CMake_VERSION_TWEAK 20130905) +set(CMake_VERSION_TWEAK 20130906) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
