[cmake-developers] [CMake 0014738]: add_test should report duplicate test
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14738 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 14738 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-06 08:05 EST Last Modified: 2014-02-06 08:05 EST == Summary:add_test should report duplicate test Description: When working in large projects is happen sometimes that two tests have the same name. It would be nice if cmake would report that. Steps to Reproduce: $ cat CMakeLists.txt project(t) enable_testing() add_test(foobar ls) add_test(foobar uptime) $ cmake . $ make test - uptime is used == Issue History Date ModifiedUsername FieldChange == 2014-02-06 08:05 Mathieu MalaterreNew Issue == -- 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] [CMake 0014739]: findboost.cmake can't find boost::mpi library
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14739
==
Reported By:Christoph Junghans
Assigned To:
==
Project:CMake
Issue ID: 14739
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-02-06 15:31 EST
Last Modified: 2014-02-06 15:31 EST
==
Summary:findboost.cmake can't find boost::mpi library
Description:
In short, Fedora installs libboost_mpi.so into
/usr/lib{,64}/{openmpi,mpich}/lib, which is why the module cannot find it.
Setting BOOST_ROOT will make the other components disappear.
Additional Information:
https://bugzilla.redhat.com/show_bug.cgi?id=756141
==
Issue History
Date ModifiedUsername FieldChange
==
2014-02-06 15:31 Christoph JunghansNew Issue
==
--
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] push of LinkOptionsCommand topic branch
I have implemented all the suggestions from the list below (modulo number 5 which needs more input from others). I have pushed the new branch to stage. SteveW On Feb 4, 2014, at 3:41 AM, Stephen Kelly steve...@gmail.com wrote: 1) Your first commit should be split up into at least two commits. The first commit in your topic should probably refactor the generators to use a new cmLocalGenerator::AddLinkOptions method which uses the LINK_FLAGS. See eg commit 35496761 where I did similar for COMPILE_FLAGS. The AddLinkOptions will have the special handling of OBJECT_LIBRARY and STATIC_LIBRARY from the Xcode generator. If that is appropriate for all generators, the commit message should say why. The second commit should add the COMPILE_OPTIONS handling to that method. My request that you create commits which change the user interface along with all supporting code to do so may have been confusing. Really what is needed is to create commits which are complete, self-contained and doing one thing at a time. That's why it makes sense to split the first commit up into two parts. If it makes sense to split it into further self-contained and complete parts, feel free to do so. I just wanted to discourage commits which are divided up by 'changes to files' rather than 'conceptual changes'. For example, changing processCompileOptionsInternal to processOptionsInternal and changing the logName at call sites could be a standalone commit preceeding your first commit. 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should linkFlags should be used with AddLinkOptions? 3) Documentation title underlines should be as long as the title, not 3 dashes longer. 4) Tests should avoid bad practices like using target_link_options to add libraries. Instead try to choose suitable link flags for the tests. On GNU, you can do this: add_executable(foo foo.cpp) target_link_options(foo PRIVATE -Wl,--ignore-unresolved-symbol,main) and write a foo.cpp which does not define main. 5) Regarding what I said before about accepting -Wl,--no-undefined versus accepting --no-undefined, I think the case of flags with arguments as above shows that only the -Wl, prefixed case should be accepted (as your branch already does). The documentation should possibly be clear that the contents of LINK_OPTIONS should be suitable for passing to the driver, not directly to the linker. 6) For the ExportImport test, you should create some export target on the Export side, and use it on the Import side. For example, on the Export side, do something like add_library(no_main_is_ok INTERFACE) target_link_options(no_main_is_ok INTERFACE -Wl,--ignore-unresolved-symbol,main) # ... Export the target. and on the Import side, add_executable(exe_no_main exe_no_main.cpp) target_link_libraries(exe_no_main no_main_is_ok) That should be done for both the import from the build tree and the install tree, as much of the existing code in Import/ does. 7) I've added two commits to your branch. Please squash them into the appropriate commits in your topic. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] [PSA] API changes to use strings
Ben Boeckel wrote:
- cmMakefile::Get{Source,Header}Extensions returns a std::set rather
than a std::vector since it was never modified and is only iterated
over and searched in other code.
The justification is strange. Generally, the guideline with C++ stl
containers is to use std::vector unless you have a good reason to use
something else.
vec[vec.size()-1] (use *vec.rbegin())
vec.back() ?
The goal of all of this? To make CMake faster by removing the chaff in
callgrind runs. String allocations and strlen/memcmp in string/C string
comparisons are way too high and hide other bottlenecks, so I'm whacking
the vast majority of problems with a very large hammer here.
Thanks, I support it.
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-developers] push of LinkOptionsCommand topic branch
Steve Wilson wrote: I have implemented all the suggestions from the list below (modulo number 5 which needs more input from others). I have pushed the new branch to stage. Great, thanks! I looked through it and the division among the commits looks good to me now. There are a few things I'd like to touch up a bit. How comfortable are you with git? Would it cause problems for you if I force push your branch, or would you know how to handle that? Do you have further local changes? 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
Re: [cmake-developers] push of LinkOptionsCommand topic branch
On Feb 6, 2014, at 3:56 PM, Stephen Kelly steve...@gmail.com wrote: There are a few things I'd like to touch up a bit. How comfortable are you with git? Would it cause problems for you if I force push your branch, or would you know how to handle that? Do you have further local changes? I’m a relative git newbie. I can get around ok and am learning a bunch as I go. The term ‘force push’ isn’t familiar though so I’m afraid you’ll have to explain (or I can look it up). I do not have any more local changes. I’ve switched to working on a different feature. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] add_custom_command differences in tests
I have my topic branch with the add_custom_command changes to include the CONFIG keyword working.The CMake binary produced from the build will correctly generated build systems that have custom commands with the CONFIG keyword. I’m having trouble writing tests for the changes though. When I run add_custom_command with the CONFIG keyword in the test suite the CONFIG keyword does not work. I need a little guidance with the test suite. I’m not super familiar with CTest so I’m not sure where to look next to find the problem. So my question: Why would add_custom_command behave differently in the tests than in regular build system generation? Thank for any help. SteveW signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] [CMake 0014741]: FindCXXFeatures (in branch next) does not work
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14741 == Reported By:nicolasmartin3d Assigned To: == Project:CMake Issue ID: 14741 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-06 21:17 EST Last Modified: 2014-02-06 21:17 EST == Summary:FindCXXFeatures (in branch next) does not work Description: Hi, I know the file is not part of current release, but still I think this is a bug if it the file is included as is. I tested the module FindCXXFeatures.cmake in the branch next, and it did not work. This is because the file skipped over the check for features, and directly failed. Changing : foreach (_cxx_feature IN LISTS CXXFEATURES_FIND_COMPONENTS) to : foreach (_cxx_feature IN LISTS CXXFeatures_FIND_COMPONENTS) did the trick. I would like to add the check for another feature, in particular for std::thread. Should I open another ticket for this ? == Issue History Date ModifiedUsername FieldChange == 2014-02-06 21:17 nicolasmartin3dNew Issue == -- 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] add_custom_command differences in tests
On Thu, Feb 06, 2014 at 17:30:11 -0700, Steve Wilson wrote: I have my topic branch with the add_custom_command changes to include the CONFIG keyword working.The CMake binary produced from the build will correctly generated build systems that have custom commands with the CONFIG keyword. I’m having trouble writing tests for the changes though. When I run add_custom_command with the CONFIG keyword in the test suite the CONFIG keyword does not work. I need a little guidance with the test suite. I’m not super familiar with CTest so I’m not sure where to look next to find the problem. So my question: Why would add_custom_command behave differently in the tests than in regular build system generation? Hmm. Are you using your installed ctest or the build tree's ctest? If the former, it may be using your installed cmake. --Ben -- 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] [PSA] API changes to use strings
On Thu, Feb 06, 2014 at 23:44:51 +0100, Stephen Kelly wrote:
Ben Boeckel wrote:
- cmMakefile::Get{Source,Header}Extensions returns a std::set rather
than a std::vector since it was never modified and is only iterated
over and searched in other code.
The justification is strange. Generally, the guideline with C++ stl
containers is to use std::vector unless you have a good reason to use
something else.
It's read-only after construction, so with std::set we get
std::binary_search for free since we never have to pay set's insertion
penalty over time.
vec[vec.size()-1] (use *vec.rbegin())
vec.back() ?
Err, for vectors, that works. I got mixed up with my examples. For
std::string, you need .rbegin() since .back() is C++11 there.
--Ben
--
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] [PSA] API changes to use strings
Ben Boeckel wrote:
On Thu, Feb 06, 2014 at 23:44:51 +0100, Stephen Kelly wrote:
Ben Boeckel wrote:
- cmMakefile::Get{Source,Header}Extensions returns a std::set rather
than a std::vector since it was never modified and is only iterated
over and searched in other code.
The justification is strange. Generally, the guideline with C++ stl
containers is to use std::vector unless you have a good reason to use
something else.
It's read-only after construction, so with std::set we get
std::binary_search for free since we never have to pay set's insertion
penalty over time.
I see.
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
Re: [CMake] Using a toplevel CMakeList.txt to build all sub projects at once.
On 06/02/14 07:14, PCMan wrote: Hello, I'm PCMan, one of the developers of LXDE desktop (now LxQt after merged with Razor-qt project). http://lxde.org/ and http://razor-qt.org/ We're migrating from gtk+ to Qt and autotools to CMake and encountered some issues. There are many small modules or components in our project. Each of them has their own CMakeLists.txt and can be built separately. However, it's hard to build so many projects manually. So we'd like to create a toplevel CMakeLists.txt to build them all at once. However, the small projects depend on each other. For example, our project layout look like this: libqtxdg - a base lib required by others liblxqt - a library depends on libqtxdg lxqt-config - a tool depends on liblxqt and libqtxdg. To build lxqt-config, liblxqt and libqtxdg need to be installed first. So simply adding them using add_subdirectoyy() won't work. When configuring lxqt-config, liblxqt needs to be installed first. To configure and compile liblxqt, cmake modules and headers from libqtxdg are required so libqtxdg needs to be installed first. Is it possible to use CMake to build them all at once since one component requires that the other is installed first. Even worse, two of our components are still automake-based. The cmake ExternalProject_Add() command did not solve the problem that some of them needs to be installed first before others can be compiled. I tried to google and read the existing docs but remain clueless. We're stuck! Any help is really appreciated. Thank you very much! Hi PCMan, It depends very much on what you mean by installed. We're in a similar situation. We have a lot of so-called packages in our project, that can depend on other (internal) packages. I've setup a build system, using CMake, that can build these packages in the right order without actually installing them. We don't have any Autotools-based packages, but it shouldn't be too hard (I guess) to wrap these as a separate package. Best regards, Marcel Loose. attachment: loose.vcf-- 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] Overriding found jpeg
Hi, I'm trying to build an open source package (openimageio, if it matters) and would like to have cmake use a specific build of the jpeg library for that project. It looks like the jpeg library that's used is determined in the line: find_package (JPEG REQUIRED) So I'd like to modify the behaviour of that command so that it finds the lib and include files that I've custom built at, say, /myjpeg/lib/libjpeg.a, etc Is there an easy way to do this? I would prefer if I could guarantee that it doesn't pick up the system libjpeg.a file. cheers, Ramin -- 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] Overriding found jpeg
Am 06.02.2014 13:02, schrieb Ramin Kamal: Hi, I'm trying to build an open source package (openimageio, if it matters) and would like to have cmake use a specific build of the jpeg library for that project. It looks like the jpeg library that's used is determined in the line: find_package (JPEG REQUIRED) So I'd like to modify the behaviour of that command so that it finds the lib and include files that I've custom built at, say, /myjpeg/lib/libjpeg.a, etc Is there an easy way to do this? I would prefer if I could guarantee that it doesn't pick up the system libjpeg.a file. cmake -D CMAKE_PREFIX_PATH=/opt/special_jpeg ... Eike -- -- 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] Overriding found jpeg
Thanks! I tried that, but it still finds the system library. Here's my test
setup:
% cd /tmp
% mkdir myjpeg myproj
% cd myjpeg
% mkdir lib include
% cd /usr/lib
% cp libjpeg.* /tmp/myjpeg/lib/
% cd /usr/include
% cp jpeglib.h /tmp/myjpeg/include/
% cd /tmp/myproj
% cat EOF CMakeLists.txt
cmake_minimum_required (VERSION 2.6)
project (test)
find_package(JPEG REQUIRED)
message( path is ${JPEG_LIBRARY} )
EOF
% mkdir build
% cd build
% cmake -D CMAKE_PREFIX_PATH=/tmp/myjpeg ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/lib64/ccache/gcc
-- Check for working C compiler: /usr/lib64/ccache/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found JPEG: /usr/lib64/libjpeg.so
*path is /usr/lib64/libjpeg.so*
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/myproj/build
Did I miss something simple there?
cheers,
Ramin
On Thu, Feb 6, 2014 at 12:14 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Am 06.02.2014 13:02, schrieb Ramin Kamal:
Hi,
I'm trying to build an open source package (openimageio, if it matters)
and
would like to have cmake use a specific build of the jpeg library for that
project. It looks like the jpeg library that's used is determined in the
line:
find_package (JPEG REQUIRED)
So I'd like to modify the behaviour of that command so that it finds the
lib and include files that I've custom built at, say,
/myjpeg/lib/libjpeg.a, etc
Is there an easy way to do this? I would prefer if I could guarantee that
it doesn't pick up the system libjpeg.a file.
cmake -D CMAKE_PREFIX_PATH=/opt/special_jpeg ...
Eike
--
--
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
Re: [CMake] Overriding found jpeg
On Thursday, 6. February 2014, 13:30:54, Ramin Kamal wrote: Thanks! I tried that, but it still finds the system library. Here's my test setup: I tried with basically the same steps, and it works for me. % cd /usr/lib % cp libjpeg.* /tmp/myjpeg/lib/ [...] -- Found JPEG: /usr/lib64/libjpeg.so *path is /usr/lib64/libjpeg.so* I see that you are using the libjpeg.so from /usr/lib for your /tmp/myjpeg directory, but the system libjpeg is in /usr/lib64. Could it be that the libjpeg in your custom directory is just not compatible? Does the problem appear even when you are copying the libjpeg.so from lib64 instead? Cheers, Johannes -- 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] Overriding found jpeg
That was it! Great stuff! Thank you for the help Johannes and Rolf! On Thu, Feb 6, 2014 at 12:46 PM, Johannes Zarl johannes.z...@jku.at wrote: On Thursday, 6. February 2014, 13:30:54, Ramin Kamal wrote: Thanks! I tried that, but it still finds the system library. Here's my test setup: I tried with basically the same steps, and it works for me. % cd /usr/lib % cp libjpeg.* /tmp/myjpeg/lib/ [...] -- Found JPEG: /usr/lib64/libjpeg.so *path is /usr/lib64/libjpeg.so* I see that you are using the libjpeg.so from /usr/lib for your /tmp/myjpeg directory, but the system libjpeg is in /usr/lib64. Could it be that the libjpeg in your custom directory is just not compatible? Does the problem appear even when you are copying the libjpeg.so from lib64 instead? Cheers, Johannes -- 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
Re: [CMake] Using a toplevel CMakeList.txt to build all sub projects at once.
On Thu, Feb 6, 2014 at 1:14 AM, PCMan pcman...@gmail.com wrote:
libqtxdg - a base lib required by others
liblxqt - a library depends on libqtxdg
lxqt-config - a tool depends on liblxqt and libqtxdg.
To build lxqt-config, liblxqt and libqtxdg need to be installed first.
The key is whether you can avoid the need to actually have these
installed. The first step is to use CMake's RPATH support so things
work both from the build directory and the install directory:
http://www.cmake.org/Wiki/CMake_RPATH_handling
The settings BRL-CAD has been using for this purpose are:
# use, i.e. don't skip the full RPATH for the build tree
set(CMAKE_SKIP_BUILD_RPATH FALSE)
# when building, don't use the install RPATH already
# (but later on when installing)
set(CMAKE_BUILD_WITH_INSTALL_
RPATH FALSE)
# the RPATH/INSTALL_NAME_DIR to be used when installing
if (NOT APPLE)
set(CMAKE_INSTALL_RPATH
${CMAKE_INSTALL_PREFIX}/${LIB_DIR}:\$ORIGIN/../${LIB_DIR})
endif(NOT APPLE)
# On OSX, we need to set INSTALL_NAME_DIR instead of RPATH
#
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_INSTALL_NAME_DIR
set(CMAKE_INSTALL_NAME_DIR ${CMAKE_INSTALL_PREFIX}/${LIB_DIR})
# add the automatically determined parts of the RPATH which point to
# directories outside the build tree to the install RPATH
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
So simply adding them using add_subdirectoy() won't work.
The second step (after the above) is to populate the *LIBNAME*_LIBRARY
and related variables that the Find*LIBNAME*.cmake (or whatever your
sub-projects are using to find their needed libraries) with the build
target names of the libraries instead of the paths. CMake will
successfully interpret the build targets in place of the installed
library paths if those libraries are part of the current CMake build.
When configuring lxqt-config, liblxqt needs to be installed first.
To configure and compile liblxqt, cmake modules and headers from
libqtxdg are required so libqtxdg needs to be installed first.
Using the above steps, lxqt-config's configure step should see the
build target location for liblxqt. The question now becomes a matter
of whether there is anything in the libraries or lxqt-config that
assumes absolute placement of resource files in install paths during
compilation. If you don't have anything making such assumptions, the
above two steps may be enough.
Is it possible to use CMake to build them all at once since one
component requires that the other is installed first.
Building them all at once shouldn't be necessary, barring other
issues... Since you're building libraries and then an executable, I'd
be fairly surprised if you encounter major difficulties - the
meta-project including the others with add_subdirectory should sort
out the build dependencies.
The *real* challenge is if you need to not just build lxqt-config but
also *run* it from the build directory without installing it. If
lxqt-config or its libraries make assumptions about the location of
resource files that involve install paths, those assumptions will
naturally fail in the build directory. BRL-CAD encountered a number
of these issues (Tcl packages were especially entertaining) but in the
end all of them proved solvable and today you can run all of BRL-CAD
from the build directory. If you *don't* need to run programs in the
build directory as part of your build and/or testing process, things
are much simpler.
Even worse, two of our components are still automake-based.
The cmake ExternalProject_Add() command did not solve the problem that
some of them needs to be installed first before others can be
compiled.
Ah. This is probably the fly in the soup. There may be other
solutions, but in the end I wound up creating several CMake build
systems for third party components simply to make everything work
without requiring the install step as part of the CMake build step.
This proved worthwhile for several other reasons, not the least of
which was that at least some of the autotools projects we were using
would have needed new build system work anyway to function with Visual
Studio, but if you're not interested in Windows/MSVC it's a bit more
of a dilemma. How come two of the components have remained with
Autotools? Is the plan to eventually migrate them?
I tried to google and read the existing docs but remain clueless.
We're stuck! Any help is really appreciated.
Thank you very much!
You can take a look at what BRL-CAD does since we do solve this
problem or at least a very similar one, but unfortunately our
third-party logic is rather complicated - we have a system that allows
for using system or bundled components in a variety of combinations
based on user settings and autodetection, which may prove to be
overkill for your situation:
http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/other/CMakeLists.txt
http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/misc/CMake/ThirdParty.cmake
See
[CMake] Early registration ends soon for CMake Santa Fe course
Don't forget to register for Kitware's CMake course in Santa Fe. Early registration ends February 12, 2014. http://training.kitware.fr/browse/52 -Bill -- 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] Determining appropriate CMAKE_MINIMUM_REQUIRED
Is there a way to get cmake to report back an _actual_ minimum required version? Our project has lots of parts, and the CMakeLists.txt have not been very well maintained. Right now, CMAKE_MINIMUM_REQUIRED is set to different values throughout, none of which are likely correct. It seems like it 'ought to be possible' to run a new version of cmake and have it report out actual values for CMAKE_MINIMUM_REQUIRED. Is there any way to do this other than a manual audit? Best, Rob -- 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] Determining appropriate CMAKE_MINIMUM_REQUIRED
On 2014-02-06 11:09-0800 Rob McDonald wrote: Is there a way to get cmake to report back an _actual_ minimum required version? Our project has lots of parts, and the CMakeLists.txt have not been very well maintained. Right now, CMAKE_MINIMUM_REQUIRED is set to different values throughout, none of which are likely correct. It seems like it 'ought to be possible' to run a new version of cmake and have it report out actual values for CMAKE_MINIMUM_REQUIRED. Is there any way to do this other than a manual audit? I don't think so. Of course, finding all the instances of cmake_minimum_required throughout your project should be trivial. For example, on linux you could use find top-level-directory-of project -type f \ |xargs grep -il cmake_minimum_required (with a slighly more complex syntax required if your paths include spaces). Changing all the uses of cmake_minimum_required to a common minimum version is extremely worthwhile in my opinion. I assume you could do that by including a common file in each of your subprojects, but I have never had to do that (my project only has two calls to cmake_minimum_required which are easy to keep in synch manually) so I will let others comment on details of the implementation. You will probably want to convert each subproject to that common minimum version approach just one subproject at a time since each such change to that minimum version is equivalent (since you say the CMake code is not well maintained so the current minimum versions are likely to be quite old) to a large number of CMake policy changes for the associated subproject which very likely will require some fixups to the CMake code for that subproject. Once all your subprojects are converted to the common minimum version approach and the common policies that implies, then updating that common minimum version should be fairly trivial. If you are keeping your common minimum version fairly up to date, then any change to that value implies relatively few or no policy changes for each of your subprojects so the needed adjustment of the CMake code in those subprojects should be small or nonexistent. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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] Determining appropriate CMAKE_MINIMUM_REQUIRED
Alan W. Irwin wrote: I assume you could do that by including a common file in each of your subprojects, but I have never had to do that (my project only has two calls to cmake_minimum_required which are easy to keep in synch manually) so I will let others comment on details of the implementation. You would need to consider the NO_POLICY_SCOPE argument to include() and whether it is needed. Thanks, Steve. -- 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] Antwort: Re: Linked Resources in Eclipse Generator
On Thursday, February 06, 2014 08:45:52 AM a.gri...@erhardt-leimer.com wrote: Hey Mister Neundorf, thanks for the quick reply. Problems apear not with the generated files explicit, but with the linked resources in general. In our case the GDB Hardware Debugging and the Subversive Plugin seem to throw cryptic exceptions, just because of the linked resources. If they are generated or set by hand doesn't matter. So it's no CMake related Problem. it would be great if somebody could take the time to fix the issues Eclipse has... it's mostly with out-of-source projects. IMO it shouldn't be hard for somebody who knows: instead of using the directory where the project file is located, add a new tag to the project file pointing to the base directory to be used instead. Just one last question remaining: Why does this flag, CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES, not completely disables linked resources as it sound the name? sounds like a bug. Can you enter it in the bug tracker at http://public.kitware.com/Bug please ? Thanks Alex -- 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] Path too long
All, I'm building FLTK as an ExternalProject to a 'Libraries' project. Inside the ExternalProject, I'm using the FLTK CMake build system. I've then created a SuperProject to build Libraries as an ExternalProject (and my main project too). This works great so far on my Mac. On my Windows machine, this results in a path name longer than 256 characters for the innermost FLTK CMake run. This fails to write a file, which causes the build to fail. Which causes the whole thing to fall down. The specific innermost error is this 5CUSTOMBUILD : CMake error : cannot write to file C:/Users/ramcdona/Documents/OpenVSP/refactor/build/super/Libraries-prefix/src/Libraries-build/FLTK-prefix/src/FLTK-build/CMakeFiles/Export/C_/Users/ramcdona/Documents/OpenVSP/refactor/build/super/Libraries-prefix/src/Libraries-build/FLTK-prefix/CMake/FLTKLibraries.cmake: No such file or directory Beautiful, isn't it? Although I can obviously work around this by using some alternate less-buried directory, that is a fragile solution that is not user-proof. Is there some way around this? What have other projects with big SuperBuild's done? Rob -- 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] a question on ExternalProject_Add
Hi folks,
I'm using VS2012+cmake2.8.12. My problem is that CMake failed to generate
the correct path to my external project. For example:
Project({...}) = external, external.vcxproj, ...
whereas 'external.vcxproj' should be something like
..\path\to\external.vcxproj
Here is how I use ExternalProject_Add command:
ExternalProject_Add(external SOURCE_DIR
${CMAKE_SOURCE_DIR}/../../int/external CMAKE_ARGS ..
BINARY_DIR ${CMAKE_SOURCE_DIR}/../../int/external/build)
Any help is highly appreciated!
Yifei
--
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, next, updated. v2.8.12.2-7466-g4235aa0
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, next has been updated
via 4235aa09c5a1e6f4ef12b5ee5dc76e2f2b0aa78c (commit)
via 6c755f0bf995e157e14e442d439d1778769f7014 (commit)
from 55d6db540d54784565ddd2914c8451c8212a048a (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=4235aa09c5a1e6f4ef12b5ee5dc76e2f2b0aa78c
commit 4235aa09c5a1e6f4ef12b5ee5dc76e2f2b0aa78c
Merge: 55d6db5 6c755f0
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Thu Feb 6 10:12:40 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 6 10:12:40 2014 -0500
Merge topic 'gcc-ipo' into next
6c755f0b IPO: involve the linker to more reliably check for gcc LTO support
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c755f0bf995e157e14e442d439d1778769f7014
commit 6c755f0bf995e157e14e442d439d1778769f7014
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Thu Feb 6 16:11:10 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Thu Feb 6 16:11:10 2014 +0100
IPO: involve the linker to more reliably check for gcc LTO support
diff --git a/Modules/Compiler/GNU.cmake b/Modules/Compiler/GNU.cmake
index 2208a06..c135ec3 100644
--- a/Modules/Compiler/GNU.cmake
+++ b/Modules/Compiler/GNU.cmake
@@ -76,32 +76,33 @@ macro(__compiler_gnu lang)
endif()
if(CMAKE_GCC_AR AND CMAKE_GCC_RANLIB)
-if(NOT DEFINED CMAKE_${lang}_HAS_COLLECT_LTO_WRAPPER)
+set(__lto_flags -flto)
+
+if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.7)
+ list(APPEND __lto_flags -fno-fat-lto-objects)
+endif()
+
+if(NOT DEFINED CMAKE_${lang}_PASSED_LTO_TEST)
execute_process(
-COMMAND ${CMAKE_${lang}_COMPILER} ${CMAKE_${lang}_VERBOSE_FLAG}
+COMMAND ${CMAKE_COMMAND} -E echo int main() {}
+COMMAND ${CMAKE_${lang}_COMPILER} ${__lto_flags} -xc -
+ -o ${CMAKE_PLATFORM_INFO_DIR}/lto-test-${lang}
RESULT_VARIABLE __result
-ERROR_VARIABLE __output
+ERROR_QUIET
OUTPUT_QUIET
)
set(__lto_found FALSE)
- if(${__result} STREQUAL 0 AND
-${__output} MATCHES COLLECT_LTO_WRAPPER)
-
+ if(${__result} STREQUAL 0)
set(__lto_found TRUE)
endif()
- set(CMAKE_${lang}_HAS_COLLECT_LTO_WRAPPER
+ set(CMAKE_${lang}_PASSED_LTO_TEST
${__lto_found} CACHE INTERNAL
-If the output of gcc -v contains COLLECT_LTO_WRAPPER)
+If the compiler passed a simple LTO test compile)
endif()
-if(CMAKE_${lang}_HAS_COLLECT_LTO_WRAPPER)
- set(__lto_flags -flto)
-
- if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.7)
-list(APPEND __lto_flags -fno-fat-lto-objects)
- endif()
+if(CMAKE_${lang}_PASSED_LTO_TEST)
set(CMAKE_${lang}_COMPILE_OPTIONS_IPO ${__lto_flags})
---
Summary of changes:
Modules/Compiler/GNU.cmake | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1357-g0795aed
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 0795aed6380dfbacec2b46c2031c3802be3bdc7c (commit) via 0f5dfd10ba430fc9377654ca8cf3f636901aa223 (commit) from d5c54d0069224000b28ad942fbf84a3de8729970 (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=0795aed6380dfbacec2b46c2031c3802be3bdc7c commit 0795aed6380dfbacec2b46c2031c3802be3bdc7c Merge: d5c54d0 0f5dfd1 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Feb 6 11:10:24 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 6 11:10:24 2014 -0500 Merge topic 'Qt4-WIN32-doc' 0f5dfd10 Help: Specify that qtmain.lib is only used for WIN32 executables. --- Summary of changes: Modules/FindQt4.cmake |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7473-gff39b3d
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, next has been updated
via ff39b3d5b4230cb898e24efde73463889aae5534 (commit)
via 78be324762f686fbd83591e3d0bba05f7844d823 (commit)
from a858432a59f86e69c2abebe0dfdaafef7ce7a098 (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=ff39b3d5b4230cb898e24efde73463889aae5534
commit ff39b3d5b4230cb898e24efde73463889aae5534
Merge: a858432 78be324
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 6 11:14:24 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 6 11:14:24 2014 -0500
Merge topic 'test-CheckModules-speedup' into next
78be3247 Tests: Speed up RunCMake.CheckModules test
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78be324762f686fbd83591e3d0bba05f7844d823
commit 78be324762f686fbd83591e3d0bba05f7844d823
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 6 11:12:50 2014 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Feb 6 11:12:50 2014 -0500
Tests: Speed up RunCMake.CheckModules test
Enable the C and CXX languages only in the test cases that really need
them. In the failure cases we do not get far enough to really use the
languages, so skip enabling them.
diff --git a/Tests/RunCMake/CheckModules/CMakeLists.txt
b/Tests/RunCMake/CheckModules/CMakeLists.txt
index 65ac8e8..72abfc8 100644
--- a/Tests/RunCMake/CheckModules/CMakeLists.txt
+++ b/Tests/RunCMake/CheckModules/CMakeLists.txt
@@ -1,3 +1,3 @@
cmake_minimum_required(VERSION 2.8.11)
-project(${RunCMake_TEST})
+project(${RunCMake_TEST} NONE)
include(${RunCMake_TEST}.cmake)
diff --git a/Tests/RunCMake/CheckModules/CheckStructHasMemberOk.cmake
b/Tests/RunCMake/CheckModules/CheckStructHasMemberOk.cmake
index b319e18..4c064c5 100644
--- a/Tests/RunCMake/CheckModules/CheckStructHasMemberOk.cmake
+++ b/Tests/RunCMake/CheckModules/CheckStructHasMemberOk.cmake
@@ -1,3 +1,5 @@
+enable_language(C)
+enable_language(CXX)
include(CheckStructHasMember)
check_struct_has_member(struct timeval tv_sec sys/select.h
HAVE_TIMEVAL_TV_SEC)
check_struct_has_member(struct timeval tv_sec sys/select.h
HAVE_TIMEVAL_TV_SEC_C LANGUAGE C)
diff --git a/Tests/RunCMake/CheckModules/CheckTypeSizeOk.cmake
b/Tests/RunCMake/CheckModules/CheckTypeSizeOk.cmake
index 558f07e..45a4978 100644
--- a/Tests/RunCMake/CheckModules/CheckTypeSizeOk.cmake
+++ b/Tests/RunCMake/CheckModules/CheckTypeSizeOk.cmake
@@ -1,3 +1,5 @@
+enable_language(C)
+enable_language(CXX)
include(CheckTypeSize)
check_type_size(int SIZEOF_INT)
check_type_size(int SIZEOF_INT BUILTIN_TYPES_ONLY)
---
Summary of changes:
Tests/RunCMake/CheckModules/CMakeLists.txt |2 +-
Tests/RunCMake/CheckModules/CheckStructHasMemberOk.cmake |2 ++
Tests/RunCMake/CheckModules/CheckTypeSizeOk.cmake|2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1359-gf555281
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 f55528186a9ff607cbf369299253957848314dd5 (commit) via 12d6eb639d3fc7dd9b9a1280d462a47c5f123120 (commit) from 0795aed6380dfbacec2b46c2031c3802be3bdc7c (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=f55528186a9ff607cbf369299253957848314dd5 commit f55528186a9ff607cbf369299253957848314dd5 Merge: 0795aed 12d6eb6 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Feb 6 11:10:25 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 6 11:10:25 2014 -0500 Merge topic 'FindOpenSSL-root-dir' 12d6eb63 FindOpenSSL: Honor OPENSSL_ROOT_DIR everywhere (#14735) --- Summary of changes: Modules/FindOpenSSL.cmake |9 + 1 file changed, 5 insertions(+), 4 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7478-g1854c3e
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, next has been updated via 1854c3ea2181a0b38b9cf39d227a97c2595edfc5 (commit) via d8fb023ddd4065bf7cc0eea9dda502bd2c26237d (commit) from 8395352b939899f7340683f551170d6a8e0e2fd0 (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=1854c3ea2181a0b38b9cf39d227a97c2595edfc5 commit 1854c3ea2181a0b38b9cf39d227a97c2595edfc5 Merge: 8395352 d8fb023 Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Feb 6 13:16:48 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 6 13:16:48 2014 -0500 Merge topic 'update-buildsystem-docs' into next d8fb023d Fix link. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8fb023ddd4065bf7cc0eea9dda502bd2c26237d commit d8fb023ddd4065bf7cc0eea9dda502bd2c26237d Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Feb 6 19:14:14 2014 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Thu Feb 6 19:14:14 2014 +0100 Fix link. diff --git a/Help/prop_tgt/ALIASED_TARGET.rst b/Help/prop_tgt/ALIASED_TARGET.rst index b04048b..f9e6034 100644 --- a/Help/prop_tgt/ALIASED_TARGET.rst +++ b/Help/prop_tgt/ALIASED_TARGET.rst @@ -3,5 +3,5 @@ ALIASED_TARGET Name of target aliased by this target. -If this is an :ref:`Alias Targets Alias Target`, this property contains +If this is an :ref:`Alias Target Alias Targets`, this property contains the name of the target aliased. --- Summary of changes: Help/prop_tgt/ALIASED_TARGET.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7476-g8395352
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, next has been updated via 8395352b939899f7340683f551170d6a8e0e2fd0 (commit) via 257ee81b00176e9c8bb18ce42313a9075b8a7b60 (commit) via cc2b13a6b994953c8b1d66e82a90c2c3f6927923 (commit) from ff39b3d5b4230cb898e24efde73463889aae5534 (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=8395352b939899f7340683f551170d6a8e0e2fd0 commit 8395352b939899f7340683f551170d6a8e0e2fd0 Merge: ff39b3d 257ee81 Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Feb 6 13:09:59 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 6 13:09:59 2014 -0500 Merge topic 'update-buildsystem-docs' into next 257ee81b Fix hyperlink anchor names and text. cc2b13a6 Move style section. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=257ee81b00176e9c8bb18ce42313a9075b8a7b60 commit 257ee81b00176e9c8bb18ce42313a9075b8a7b60 Author: Stephen Kelly steve...@gmail.com AuthorDate: Thu Feb 6 19:02:01 2014 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Thu Feb 6 19:02:01 2014 +0100 Fix hyperlink anchor names and text. diff --git a/Help/command/add_executable.rst b/Help/command/add_executable.rst index 296adc3..231eeed 100644 --- a/Help/command/add_executable.rst +++ b/Help/command/add_executable.rst @@ -44,7 +44,7 @@ buildsystem properties. add_executable(name IMPORTED [GLOBAL]) -An :ref:`IMPORTED executable target Imported Target` references an +An :ref:`IMPORTED executable target Imported Targets` references an executable file located outside the project. No rules are generated to build it, and the :prop_tgt:`IMPORTED` target property is ``True``. The target name has scope in the directory in which it is created and below, but @@ -64,10 +64,10 @@ properties for more information. add_executable(name ALIAS target) -Creates an :ref:`Alias Target`, such that ``name`` can +Creates an :ref:`Alias Target Alias Targets`, such that ``name`` can be used to refer to ``target`` in subsequent commands. The ``name`` does not appear in the generated buildsystem as a make target. The -``target`` may not be an :ref:`Imported Target` or an +``target`` may not be an :ref:`Imported Target Imported Targets` or an ``ALIAS``. ``ALIAS`` targets can be used as targets to read properties from, executables for custom commands and custom targets. They can also be tested for existance with the regular :command:`if(TARGET)` subcommand. diff --git a/Help/command/add_library.rst b/Help/command/add_library.rst index 6450485..0944269 100644 --- a/Help/command/add_library.rst +++ b/Help/command/add_library.rst @@ -49,7 +49,7 @@ properties. add_library(name SHARED|STATIC|MODULE|UNKNOWN IMPORTED [GLOBAL]) -An :ref:`IMPORTED library target Imported Target` references a library +An :ref:`IMPORTED library target Imported Targets` references a library file located outside the project. No rules are generated to build it, and the :prop_tgt:`IMPORTED` target property is ``True``. The target name has scope in the directory in which it is created and below, but the ``GLOBAL`` @@ -97,10 +97,10 @@ adding at least one real source file to any target that references add_library(name ALIAS target) -Creates an :ref:`Alias Target`, such that ``name`` can be +Creates an :ref:`Alias Target Alias Targets`, such that ``name`` can be used to refer to ``target`` in subsequent commands. The ``name`` does not appear in the generatedbuildsystem as a make target. The ``target`` -may not be an :ref:`Imported Target` or an ``ALIAS``. +may not be an :ref:`Imported Target Imported Targets` or an ``ALIAS``. ``ALIAS`` targets can be used as linkable targets and as targets to read properties from. They can also be tested for existance with the regular :command:`if(TARGET)` subcommand. The ``name`` may not be used @@ -115,21 +115,22 @@ installed or exported. add_library(name INTERFACE [IMPORTED [GLOBAL]]) -Creates an :ref:`Interface Library`. An ``INTERFACE`` library target does -not directly create build output, though it may have properties set on it -and it may be installed, exported and imported. Typically the -``INTERFACE_*`` properties are populated on the interface target using the -:command:`set_property`, :command:`target_link_libraries(INTERFACE)`, +Creates an :ref:`Interface Library Interface Libraries`. An ``INTERFACE`` +library target does not directly create build output, though it may +have properties set on it and it may be installed, exported and +imported. Typically the ``INTERFACE_*`` properties are
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7491-g694e750
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, next has been updated via 694e750bba0f6b9f0242d90c57611864ee3edcc8 (commit) via 8b5a2be329d2808d178ed3c9e75f8ca5812e32bc (commit) from f52d85f03a110a942480b9610ed129867290d696 (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=694e750bba0f6b9f0242d90c57611864ee3edcc8 commit 694e750bba0f6b9f0242d90c57611864ee3edcc8 Merge: f52d85f 8b5a2be Author: Brad King brad.k...@kitware.com AuthorDate: Thu Feb 6 16:11:26 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 6 16:11:26 2014 -0500 Merge topic 'update-buildsystem-docs' into next 8b5a2be3 Help: Fix typo in style guide http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8b5a2be329d2808d178ed3c9e75f8ca5812e32bc commit 8b5a2be329d2808d178ed3c9e75f8ca5812e32bc Author: Brad King brad.k...@kitware.com AuthorDate: Thu Feb 6 16:05:22 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Feb 6 16:05:22 2014 -0500 Help: Fix typo in style guide diff --git a/Help/manual/cmake-developer.7.rst b/Help/manual/cmake-developer.7.rst index 3d54304..887047c 100644 --- a/Help/manual/cmake-developer.7.rst +++ b/Help/manual/cmake-developer.7.rst @@ -503,7 +503,7 @@ Style .. code-block:: rst -This command creates an :ref:`Imported Target Imported Targets`. +This command creates an :ref:`Imported Target Imported Targets`. instead of: --- Summary of changes: Help/manual/cmake-developer.7.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1371-g6abdc6c
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 6abdc6c16acec3cb6601cc0bdeba4dec30857a02 (commit) via cc46b702d04d4bcfef76db547054533f3a62a8fa (commit) via f371545d3b2b77ad1456f6175e7580ce049f8a68 (commit) via 3879c847825d40a439b0ec55421309ab9b33c1ee (commit) via ba4c2fa8fd2a03f7d69e60d581d44a3cc79a3c9a (commit) via a683262a727c4fd2c9e3271e6bc36679d0963342 (commit) via fbe01bedbe827469e0737316a8720283c33c9583 (commit) via 645500b413d501133bbb78548d611f49c91ae2cb (commit) via 85a4fad78c187ef6b595a62d01e1f7b534c45fe3 (commit) via a0fa025377ebe15af5303e47455f58391e9d6994 (commit) via 6c02e7f427aa8d52b7bff2ddcf3932200a8f917b (commit) via 91fbff88202398fdf0e74cffc0681c32cbb7d061 (commit) from f55528186a9ff607cbf369299253957848314dd5 (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=6abdc6c16acec3cb6601cc0bdeba4dec30857a02 commit 6abdc6c16acec3cb6601cc0bdeba4dec30857a02 Merge: f555281 cc46b70 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Feb 6 16:19:02 2014 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Feb 6 16:19:02 2014 -0500 Merge topic 'update-buildsystem-docs' cc46b702 Help: Adjust the QtAutogen properties to the common style. f371545d Help: Use ``True`` and ``False`` for IMPORTED values. 3879c847 Help: Document relation of properties to the rest of the buildsystem. ba4c2fa8 Help: Mark up the buildsystem commands documentation a683262a Help: Note that the compatible interface properties must not intersect. fbe01bed Help: Specify how to order and modify transitively set property values. 645500b4 Help: Add hyperlink targets to some manual sections. 85a4fad7 Help: Use ``inline-literals`` to mark generator expressions. a0fa0253 Help: Mark up references to NEW and OLD policy settings properly. 6c02e7f4 Help: Add a style guide. 91fbff88 Help: Fix typos --- Summary of changes: Help/command/add_compile_options.rst | 17 +- Help/command/add_custom_command.rst|2 +- Help/command/add_definitions.rst | 24 ++- Help/command/add_executable.rst| 82 - Help/command/add_library.rst | 167 +- Help/command/add_test.rst |2 +- Help/command/include_directories.rst | 33 ++-- Help/command/target_compile_definitions.rst| 32 ++-- Help/command/target_compile_options.rst| 40 +++-- Help/command/target_include_directories.rst| 47 +++--- Help/command/target_link_libraries.rst | 177 ++-- Help/manual/cmake-buildsystem.7.rst| 37 +++- Help/manual/cmake-developer.7.rst | 171 ++- Help/manual/cmake-policies.7.rst |8 +- Help/prop_dir/COMPILE_DEFINITIONS.rst | 24 ++- Help/prop_dir/COMPILE_DEFINITIONS_CONFIG.rst | 11 +- Help/prop_dir/COMPILE_OPTIONS.rst | 16 +- Help/prop_dir/INCLUDE_DIRECTORIES.rst | 28 ++-- Help/prop_tgt/ALIASED_TARGET.rst |4 +- Help/prop_tgt/AUTOGEN_TARGET_DEPENDS.rst |5 +- Help/prop_tgt/AUTOMOC.rst | 13 +- Help/prop_tgt/AUTOMOC_MOC_OPTIONS.rst | 13 +- Help/prop_tgt/AUTORCC.rst | 14 +- Help/prop_tgt/AUTORCC_OPTIONS.rst | 16 +- Help/prop_tgt/AUTOUIC.rst | 18 +- Help/prop_tgt/AUTOUIC_OPTIONS.rst | 20 ++- Help/prop_tgt/COMPATIBLE_INTERFACE_BOOL.rst| 29 ++-- Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MAX.rst | 25 +-- Help/prop_tgt/COMPATIBLE_INTERFACE_NUMBER_MIN.rst | 25 +-- Help/prop_tgt/COMPATIBLE_INTERFACE_STRING.rst | 20 +-- Help/prop_tgt/COMPILE_DEFINITIONS.rst | 21 ++- Help/prop_tgt/COMPILE_DEFINITIONS_CONFIG.rst | 10 +- Help/prop_tgt/COMPILE_OPTIONS.rst | 14 +- Help/prop_tgt/IMPORTED.rst |6 +- Help/prop_tgt/INCLUDE_DIRECTORIES.rst | 25 ++- Help/prop_tgt/INTERFACE_COMPILE_DEFINITIONS.rst| 12 +- Help/prop_tgt/INTERFACE_COMPILE_OPTIONS.rst| 12 +- Help/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.rst| 12 +- Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst | 11 +-
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7505-g1ba947e
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, next has been updated via 1ba947ef5870526ad00a76928306e0106989c631 (commit) via 6abdc6c16acec3cb6601cc0bdeba4dec30857a02 (commit) from 5e281a2f87ccbc9d32a8277b162a795ecb5da740 (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=1ba947ef5870526ad00a76928306e0106989c631 commit 1ba947ef5870526ad00a76928306e0106989c631 Merge: 5e281a2 6abdc6c Author: Brad King brad.k...@kitware.com AuthorDate: Thu Feb 6 16:19:49 2014 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Feb 6 16:19:49 2014 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1372-g53cffda
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 53cffda228e50948e52ae3b5bc46d4fa3f59a0ba (commit) from 6abdc6c16acec3cb6601cc0bdeba4dec30857a02 (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=53cffda228e50948e52ae3b5bc46d4fa3f59a0ba commit 53cffda228e50948e52ae3b5bc46d4fa3f59a0ba Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Feb 7 00:01:05 2014 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Feb 7 00:01:05 2014 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index cbe9af2..7945bb5 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 12) -set(CMake_VERSION_TWEAK 20140206) +set(CMake_VERSION_TWEAK 20140207) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
