[cmake-developers] [CMake 0014103]: Generator Eclipse CDT4 - Ninja does not write C++ Include paths into the generated .cproject file
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14103 == Reported By:Matthias Maier Assigned To: == Project:CMake Issue ID: 14103 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-04-22 05:10 EDT Last Modified: 2013-04-22 05:10 EDT == Summary:Generator Eclipse CDT4 - Ninja does not write C++ Include paths into the generated .cproject file Description: When I run the Eclipse CDT4 - Unix Makefiles generator, I end up with the following Includes in the generated .cproject file (shortened for better readability): pathentry include=$PREFIX/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include kind=inc path= system=true/ pathentry include=$PREFIX/usr/include kind=inc path= system=true/ pathentry include=$PREFIX/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include-fixed kind=inc path= system=true/ pathentry include=$PREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4 kind=inc path= system=true/ pathentry include=$PREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4/x86_64-pc-linux-gnu kind=inc path= system=true/ pathentry include=$PREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/include/g++-v4/backward kind=inc path= system=true/ and indexing of C++ STL headers, as well as, resolving of STL containers/methods works. However, with the Eclipse CDT4 - Ninja generator I only get: pathentry include=$PREFIX/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include kind=inc path= system=true/ pathentry include=$PREFIX/usr/include kind=inc path= system=true/ pathentry include=$PREFIX/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/include-fixed kind=inc path= system=true/ with the result that resolving STL headers fails. == Issue History Date ModifiedUsername FieldChange == 2013-04-22 05:10 Matthias Maier New 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] CMake 2.8.11-rc3 ready for testing!
May I ask one question related to the Target Usage Requirements ... For HDF5 (for example), the user might enable Parallel IO, which requires MPI. When enabled, the hdf5 cmakelists use find_package to get MPI and all is fine. Users of hdf5 might not know that they are using an hdf which has parallel IO enabled, and compilation is complicated by the unexpected dependency on mpi libs and includes Is this new feature designed to resolve this long standing irritation so that when installed, the hdf5 will add the mpi dependency behind the scenes? If so, I am delighted and would like to test it out on the hdf5 distribution. If there is a link to an example I can copy from, please say. Thanks JB -Original Message- From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Robert Maynard Sent: 19 April 2013 15:24 To: cmake-developers@cmake.org Subject: [cmake-developers] CMake 2.8.11-rc3 ready for testing! The CMake 2.8.11 release candidate continues. This is the last RC unless a critical, must-fix issue is found. You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Some of the notable changes in this release are: - Introduced Target Usage Requirements - Targets can specify usage requirements for their consumers such as include directories and preprocessor definitions; previously only link dependencies were supported - target_link_libraries(myexe yourlib) can now build myexe sources with requirements specified by yourlib - Added target_include_directories and target_compile_definitions commands with PUBLIC/PRIVATE/INTERFACE options - See design and development discussion at http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements - Introduced a Generator Toolset selection for VS = 10 and Xcode = 3 - Tell the IDEs which compiler toolchain to use - ex. Use VS 9 tools under VS 10: -G Visual Studio 10 -T v90 - Introduced ExternalData Module - Keep source trees lightweight by storing data separately - Reference data unambiguously from source tree by content hash - Fetch on-demand during build from local or remote resources - CMake: Sublime Text Generator added that supports both Make and Ninja - CMake: Added support for Texas Instruments C6 and up compilers - CMake: Improve OpenBSD support - CMake: Support for Windows CE with VS 8 and 9 generators - CPack: Added Support for 64bit NSIS - CPack: Added WiX Package Generator - ExternalProject: Will run git fetch less often - FindBoost: Major overhaul of searching and result caching - FindCUDA: Now has support for separable compilation - FindQt4: Overall improvements to finding Qt and importing targets - FindSquish: Added support for squish 4 - GetPrerequisites: Port to MinGW with objdump The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=103 Following is the complete list of changes in this rc since the previous rc. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. This release candidate will become the final release for 2.8.11 unless a serious issue is reported. Changes in CMake 2.8.11-rc3 (since 2.8.11-rc2) -- Brad King (1): get_filename_component: Document path components more clearly (#14091) Rolf Eike Beer (1): try_compile: add missing fclose() to recently added error case Stephen Kelly (1): Fix clearing of the INCLUDE_DIRECTORIES DIRECTORY property. -- 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 -- 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] CMake 2.8.11-rc3 ready for testing!
One important extra point. The MPI library was NOT built with cmake, but the HDF5 and the user's project would be. Not sure if that makes a difference JB From: Biddiscombe, John A. Sent: 22 April 2013 16:46 To: 'Stephen Kelly'; cmake-developers@cmake.org Subject: RE: [cmake-developers] CMake 2.8.11-rc3 ready for testing! Sorry, I assumed too much familiarity with hdf5/mpi Hdf5 has CMakelists.txt files and declares a number of targets. When built with parallel IO, hdf5 used find_package(MPI) to get the required libs and includes for the library to compile and link nicely with mpi. No problem When you do a make install on hdf5, it creates a set of very nice cmake files C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-debug.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-release.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config-version.cmake Which declare imported targets for debug and release and do everything right. Except that if the user picks up HDF5 using the syntax find_package(HDF5 NO_MODULE) i.e. NOT using the findhdf5 (because we want to pick up the cmake config) then the user's project has a 'hidden' dependency on mpi includes and libs and unless they add a find_package(mpi) to their project - and add the necessary include dirs. And links - theit build will fail What I'd like to di, is in the target import declared by hdf5, add in this transitive link dependency to m pi. In the past I was advised not to do this, but my hope is that this can be expressed nicely with the new syntax Yes? JB -Original Message- From: cmake-developers-boun...@cmake.orgmailto:cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: 22 April 2013 16:35 To: cmake-developers@cmake.orgmailto:cmake-developers@cmake.org Subject: Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing! Biddiscombe, John A. wrote: May I ask one question related to the Target Usage Requirements ... For HDF5 (for example), the user might enable Parallel IO, which requires MPI. When enabled, the hdf5 cmakelists use find_package to get MPI and all is fine. Hi there, I am not familiar with hdf5 or mpi. What are you referring to when you say the hdf5 cmakelists ? Do you mean FindHDF5.cmake? Users of hdf5 might not know that they are using an hdf which has parallel IO enabled, and compilation is complicated by the unexpected dependency on mpi libs and includes Can you be specific about what is more complicated? I'm not familiar with what is complicated. Is this new feature designed to resolve this long standing irritation so that when installed, the hdf5 will add the mpi dependency behind the scenes? Sort of/maybe. It is designed for use with IMPORTED targets, which in general means that the upstream uses CMake and installs a Config.cmake file. As there is a FindHDF5.cmake, I'm guessing that is not the case here. However, it would be possible to create IMPORTED targets in the Find file. However, there may be other ways of solving the problems you're experiencing regarding convenience, even without these features. Using these features has certain conveniences, but they don't seem to be what you're after. What you're after seems to be possible anyway. PNG_LIBRARIES contains ZLIB_LIBRARY for example, because it depends on it. Should HDF5_LIBRARIES contain MPI_LIBRARIES? Sorry I can't give more useful information. Maybe someone else can. Thanks, Steve. -- Powered by www.kitware.comhttp://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 -- 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] CMake 2.8.11-rc3 ready for testing!
Sorry, I assumed too much familiarity with hdf5/mpi Hdf5 has CMakelists.txt files and declares a number of targets. When built with parallel IO, hdf5 used find_package(MPI) to get the required libs and includes for the library to compile and link nicely with mpi. No problem When you do a make install on hdf5, it creates a set of very nice cmake files C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-debug.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-release.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config-version.cmake Which declare imported targets for debug and release and do everything right. Except that if the user picks up HDF5 using the syntax find_package(HDF5 NO_MODULE) i.e. NOT using the findhdf5 (because we want to pick up the cmake config) then the user's project has a 'hidden' dependency on mpi includes and libs and unless they add a find_package(mpi) to their project - and add the necessary include dirs. And links - theit build will fail What I'd like to di, is in the target import declared by hdf5, add in this transitive link dependency to m pi. In the past I was advised not to do this, but my hope is that this can be expressed nicely with the new syntax Yes? JB -Original Message- From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: 22 April 2013 16:35 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing! Biddiscombe, John A. wrote: May I ask one question related to the Target Usage Requirements ... For HDF5 (for example), the user might enable Parallel IO, which requires MPI. When enabled, the hdf5 cmakelists use find_package to get MPI and all is fine. Hi there, I am not familiar with hdf5 or mpi. What are you referring to when you say the hdf5 cmakelists ? Do you mean FindHDF5.cmake? Users of hdf5 might not know that they are using an hdf which has parallel IO enabled, and compilation is complicated by the unexpected dependency on mpi libs and includes Can you be specific about what is more complicated? I'm not familiar with what is complicated. Is this new feature designed to resolve this long standing irritation so that when installed, the hdf5 will add the mpi dependency behind the scenes? Sort of/maybe. It is designed for use with IMPORTED targets, which in general means that the upstream uses CMake and installs a Config.cmake file. As there is a FindHDF5.cmake, I'm guessing that is not the case here. However, it would be possible to create IMPORTED targets in the Find file. However, there may be other ways of solving the problems you're experiencing regarding convenience, even without these features. Using these features has certain conveniences, but they don't seem to be what you're after. What you're after seems to be possible anyway. PNG_LIBRARIES contains ZLIB_LIBRARY for example, because it depends on it. Should HDF5_LIBRARIES contain MPI_LIBRARIES? Sorry I can't give more useful information. Maybe someone else can. Thanks, Steve. -- Powered by www.kitware.comhttp://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 -- 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 0014105]: IMPORTED target for a framework not handled correctly.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14105
==
Reported By:Stephen Kelly
Assigned To:
==
Project:CMake
Issue ID: 14105
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-04-22 11:04 EDT
Last Modified: 2013-04-22 11:04 EDT
==
Summary:IMPORTED target for a framework not handled
correctly.
Description:
Given this:
cmake_minimum_required(VERSION 2.8)
project(cmake_framework_target)
find_library(COCOA_LIBRARY Cocoa)
add_library(Custom::Cocoa IMPORTED SHARED)
set_property(TARGET Custom::Cocoa APPEND PROPERTY IMPORTED_CONFIGURATIONS
RELEASE)
set_property(TARGET Custom::Cocoa PROPERTY IMPORTED_LOCATION_RELEASE
${COCOA_LIBRARY})
set_property(TARGET Custom::Cocoa PROPERTY FRAMEWORK 1)
add_executable(Framework_test main.cpp)
#target_link_libraries(Framework_test ${COCOA_LIBRARY})
target_link_libraries(Framework_test Custom::Cocoa)
Using the COCOA_LIBRARY in the tll() line works fine, linking is done with
-framework Cocoa.
However, using the IMPORTED target, cmake links with this result:
Linking CXX executable Framework_test
/Users/kdab/dev/cmake/build/bin/cmake -E cmake_link_script
CMakeFiles/Framework_test.dir/link.txt --verbose=1
/usr/bin/c++-Wl,-search_paths_first -Wl,-headerpad_max_install_names
CMakeFiles/Framework_test.dir/main.cpp.o -o Framework_test
/System/Library/Frameworks/Cocoa.framework
ld: in /System/Library/Frameworks/Cocoa.framework, can't map file, errno=22 for
architecture x86_64
collect2: ld returned 1 exit status
This patch fixes the issue, but I have no idea if it is appropriate (because I
don't have any familiarity with Mac, or how frameworks are supposed to work, or
if it is appropriate to create an imported target for a framework at all in
cmake):
diff --git a/Source/cmComputeLinkInformation.cxx
b/Source/cmComputeLinkInformation.cxx
index 896b50a..4fd32ea 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -657,14 +657,21 @@ void cmComputeLinkInformation::AddItem(std::string const
item, cmTarget* tgt)
// Pass the full path to the target file.
std::string lib = tgt-GetFullPath(config, implib, true);
- if(!this-LinkDependsNoShared ||
- tgt-GetType() != cmTarget::SHARED_LIBRARY)
+ if(cmSystemTools::FileIsDirectory(lib.c_str()))
{
-this-Depends.push_back(lib);
+this-AddDirectoryItem(lib);
}
+ else
+{
+if(!this-LinkDependsNoShared ||
+ tgt-GetType() != cmTarget::SHARED_LIBRARY)
+ {
+ this-Depends.push_back(lib);
+ }
- this-AddTargetItem(lib, tgt);
- this-AddLibraryRuntimeInfo(lib, tgt);
+this-AddTargetItem(lib, tgt);
+this-AddLibraryRuntimeInfo(lib, tgt);
+}
}
}
else
==
Issue History
Date ModifiedUsername FieldChange
==
2013-04-22 11:04 Stephen Kelly New 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] hdf5 dependency on mpi (was: CMake 2.8.11-rc3 ready for testing!)
On 04/22/2013 10:46 AM, Biddiscombe, John A. wrote: C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake find_package(HDF5 NO_MODULE) then the user’s project has a ‘hidden’ dependency on mpi In similar cases (in VTK and ITK) we have the package config file do find_package() for transitive dependencies. One may pre-populate any cache entries that the find module needs using the results from the original build tree (assuming the dependency does not move). What I’d like to di, is in the target import declared by hdf5, add in this transitive link dependency to m pi. That's basically what I describe above. In the past I was advised not to do this, but my hope is that this can be expressed nicely with the new syntax Can you link to where that advice was given? The new features do not provide a new way to solve this problem AFAIK. -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
[cmake-developers] QtDialogSearchText2 topic v. Qt 4.4.3
Alex, This topic does not build on magrathea.kitware's Linux-gcc332s dashboard: http://open.cdash.org/viewBuildError.php?buildid=2882492 .../Source/QtDialog/CMakeSetupDialog.cxx: In member function `void CMakeSetupDialog::doOutputFindDialog()': .../Source/QtDialog/CMakeSetupDialog.cxx:1212: error: `removeDuplicates' undeclared (first use this function) The machine has Qt 4.4.3 (and is used to build release binaries on Linux). -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] hdf5 dependency on mpi (was: CMake 2.8.11-rc3 ready for testing!)
Brad, Stephen OK. I can add the find_package to the hdf5-config.cmake But the user still has to add the include path to their own projects, and link each target against mpi. Paraview, for example, fails to build when you link against a system hdf5 which has parallel enabled. You have to manually change about 5 different cmakelists files to get it to work, if the hdf5_config, transitively added the link, it'd be much nicer. Can I add the #include and link into the hdf5-config.cmake? This is what I was advised not to do before. I can't find the advice on google, but will try harder if you really want it JB -Original Message- From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: 22 April 2013 17:13 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] hdf5 dependency on mpi (was: CMake 2.8.11-rc3 ready for testing!) Brad King wrote: On 04/22/2013 10:46 AM, Biddiscombe, John A. wrote: C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake find_package(HDF5 NO_MODULE) then the user’s project has a ‘hidden’ dependency on mpi In similar cases (in VTK and ITK) we have the package config file do find_package() for transitive dependencies. One may pre-populate any cache entries that the find module needs using the results from the original build tree (assuming the dependency does not move). I was going to suggest the same. The C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake file should contain find_package(mpi), if that is needed. The new features do not provide a new way to solve this problem AFAIK. As far as I understand the issue, I agree. Even if the new features were used for another reason, the need for the find_package would still be there. 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 -- 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] hdf5 dependency on mpi
On 04/22/2013 11:52 AM, Biddiscombe, John A. wrote: Can I add the #include and link into the hdf5-config.cmake? This is what I was advised not to do before. The package config file should have only declarative effects and not actually modify the loading project's build, so that advice was correct. The _INCLUDE_DIRS, _LIBRARIES, etc. variables that hdf5-config.cmake provides should already be populated with the transitive dependencies. It should be able to do this without find_package(MPI) too. -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] hdf5 dependency on mpi
I think I hit the wrong key and my email disappeared, apologies if you get this twice The package config file should have only declarative effects and not actually modify the loading project's build, so that advice was correct. Understood. This seems sensible. The _INCLUDE_DIRS, _LIBRARIES, etc. variables that hdf5-config.cmake provides should already be populated with the transitive dependencies. It should be able to do this without find_package(MPI) too. OK, that's great. I've been doing this in my builds but thought it was somehow 'wrong' in the public release. Since hdf5 already knows which mpi libs/includes are being pulled in, all is ok. One thing : Suppose hdf5 pulls in the mpi lib and includes, and the project using it requests mpi separately. Is there a correct - or standard - way of making sure the user does not choose a different mpi lib - If we know that the project using hdf5 will call find_package(MPI) then we could too in the config, and that'd actually be a good way of making sure the same one is used. If the calling project does need or use mpi itself, it can/would just confuse the user... Is there a correct way of handling this? (I'm guessing the best we can do is export a variable HDF5_MPI_INCLUDE etc etc which the user can test if concerned that the user mpi doesn't match the hdf5 mpi) Thanks again JB -- 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] hdf5 dependency on mpi
On 04/22/2013 03:32 PM, Biddiscombe, John A. wrote: Suppose hdf5 pulls in the mpi lib and includes, and the project using it requests mpi separately. Is there a correct - or standard - way of making sure the user does not choose a different mpi lib I'm not aware of a standard way to deal with this. It is tricky because the downstream project could find_package(MPI) and find_package(HDF5) in either order so there is no good place to hook in to enforce consistency. -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] Problem with get_filename_component() and CMAKE_CXX_COMPILER when finding Qt4
Am 22.04.2013 14:26, schrieb Petr Kmoch: Hi all. I'm using CMake 2.8.10.2 to do a Visual Studio 2010 64-bit build, and I encountered a weird problem with the CMake configure step failing, with the following output: CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeCXXInformation.cmake:37 (get_filename_component): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:2 (PROJECT) CMAKE_CXX_COMPILER is empty at that point. I managed to pinpoint this to an issue with try_compile in FindQt4. I am attaching a minimal test case as well as output of cmake --trace. The CMakeList is just this: I don't see a try_compile in FindQt4. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with get_filename_component() and CMAKE_CXX_COMPILER when finding Qt4
If you look at the trace, you'll see the following few lines before the
error:
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindQt4.cmake(738):
set(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES} )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindQt4.cmake(739):
set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS} )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindQt4.cmake(741):
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES};${QT_INCLUDE_DIR} )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindQt4.cmake(743):
CHECK_CXX_SYMBOL_EXISTS(Q_WS_X11 QtCore/qglobal.h Q_WS_X11 )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckCXXSymbolExists.cmake(41):
_CHECK_SYMBOL_EXISTS(${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/CheckSymbolExists.cxx
Q_WS_X11 QtCore/qglobal.h Q_WS_X11 )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(46): if(Q_WS_X11
MATCHES ^Q_WS_X11$ )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(47):
set(CMAKE_CONFIGURABLE_FILE_CONTENT /* */\n )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(48):
set(MACRO_CHECK_SYMBOL_EXISTS_FLAGS ${CMAKE_REQUIRED_FLAGS} )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(49):
if(CMAKE_REQUIRED_LIBRARIES )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(54): else()
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(55):
set(CHECK_SYMBOL_EXISTS_LIBS )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(57):
if(CMAKE_REQUIRED_INCLUDES )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(58):
set(CMAKE_SYMBOL_EXISTS_INCLUDES
-DINCLUDE_DIRECTORIES:STRING=${CMAKE_REQUIRED_INCLUDES} )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(63): foreach(FILE
QtCore/qglobal.h )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(64):
set(CMAKE_CONFIGURABLE_FILE_CONTENT
${CMAKE_CONFIGURABLE_FILE_CONTENT}#include ${FILE}\n )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(67):
set(CMAKE_CONFIGURABLE_FILE_CONTENT ${CMAKE_CONFIGURABLE_FILE_CONTENT}\nint
main(int argc, char** argv)\n{\n (void)argv;\n#ifndef Q_WS_X11\n return
((int*)(Q_WS_X11))[argc];\n#else\n (void)argc;\n return 0;\n#endif\n}\n )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(70):
configure_file(${CMAKE_ROOT}/Modules/CMakeConfigurableFile.in
D:/Tmp/cmake/bld/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx @ONLY IMMEDIATE )
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(73): message(STATUS
Looking for Q_WS_X11 )
-- Looking for Q_WS_X11
C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(74):
try_compile(Q_WS_X11 ${CMAKE_BINARY_DIR}
D:/Tmp/cmake/bld/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
COMPILE_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS} CMAKE_FLAGS
-DCOMPILE_DEFINITIONS:STRING=${MACRO_CHECK_SYMBOL_EXISTS_FLAGS}
${CHECK_SYMBOL_EXISTS_LIBS} ${CMAKE_SYMBOL_EXISTS_INCLUDES} OUTPUT_VARIABLE
OUTPUT )
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeCXXInformation.cmake:37
(get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
On Mon, Apr 22, 2013 at 3:05 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Am 22.04.2013 14:26, schrieb Petr Kmoch:
Hi all.
I'm using CMake 2.8.10.2 to do a Visual Studio 2010 64-bit build, and I
encountered a weird problem with the CMake configure step failing, with
the
following output:
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/**CMakeCXXInformation.cmake:37
(get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
CMAKE_CXX_COMPILER is empty at that point.
I managed to pinpoint this to an issue with try_compile in FindQt4. I am
attaching a minimal test case as well as output of cmake --trace. The
CMakeList is just this:
I don't see a try_compile in FindQt4.
Eike
--
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
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:
[CMake] CMake VS2011Arm patch
Hi!
I’ve developed patch for Visual Studio ARM support. (Patch file is attached)
I'd like you to try patch functionality and get a review.
With regards, Vladimir.diff --git a/cmake-2.8.10.2/Modules/CMakeTestCXXCompiler.cmake b/cmake-2.8.10.2/Modules/CMakeTestCXXCompiler.cmake
index a5cdf56..ab15319 100644
--- a/cmake-2.8.10.2/Modules/CMakeTestCXXCompiler.cmake
+++ b/cmake-2.8.10.2/Modules/CMakeTestCXXCompiler.cmake
@@ -32,11 +32,17 @@ unset(CMAKE_CXX_COMPILER_WORKS CACHE)
# any makefiles or projects.
if(NOT CMAKE_CXX_COMPILER_WORKS)
PrintTestCompilerStatus(CXX )
- file(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testCXXCompiler.cxx
-#ifndef __cplusplus\n
-# error \The CMAKE_CXX_COMPILER is set to a C compiler\\n
-#endif\n
-int main(){return 0;}\n)
+ IF(CMAKE_GENERATOR MATCHES Visual Studio 11 ARM)
+file(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testCXXCompiler.cxx
+ using namespace Platform;\n
+ int main(ArrayString^^ args) { return 0;}\n)
+ else()
+file(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testCXXCompiler.cxx
+#ifndef __cplusplus\n
+# error \The CMAKE_CXX_COMPILER is set to a C compiler\\n
+#endif\n
+int main(){return 0;}\n)
+ endif()
try_compile(CMAKE_CXX_COMPILER_WORKS ${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testCXXCompiler.cxx
OUTPUT_VARIABLE __CMAKE_CXX_COMPILER_OUTPUT)
diff --git a/cmake-2.8.10.2/Source/cmCoreTryCompile.cxx b/cmake-2.8.10.2/Source/cmCoreTryCompile.cxx
index 1ae7035..0d8c577 100644
--- a/cmake-2.8.10.2/Source/cmCoreTryCompile.cxx
+++ b/cmake-2.8.10.2/Source/cmCoreTryCompile.cxx
@@ -296,8 +296,20 @@ int cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv)
fprintf(fout, SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY \%s\)\n,
this-BinaryDirectory.c_str());
/* Create the actual executable. */
-fprintf(fout, ADD_EXECUTABLE(%s \%s\)\n, targetName, source.c_str());
-fprintf(fout, TARGET_LINK_LIBRARIES(%s ${LINK_LIBRARIES})\n,targetName);
+ if (this-Makefile-GetLocalGenerator()-isVS11ARMCurrentGlobalGenerator())
+ {
+ if(CreatePackageAppxmanifestForTest() == CREATE_MANIFEST_ERROR)
+return CREATE_MANIFEST_ERROR;
+
+ std::string packagePath = this-BinaryDirectory + /Package.appxmanifest;
+
+ fprintf(fout, ADD_EXECUTABLE(%s \%s\ \%s\)\n, targetName, source.c_str(), packagePath.c_str());
+ }
+ else{
+ fprintf(fout, ADD_EXECUTABLE(%s \%s\)\n, targetName, source.c_str());
+ }
+ fprintf(fout, TARGET_LINK_LIBRARIES(%s ${LINK_LIBRARIES})\n, targetName);
+
fclose(fout);
projectName = CMAKE_TRY_COMPILE;
// if the source is not in CMakeTmp
@@ -481,3 +493,59 @@ void cmCoreTryCompile::FindOutputFile(const char* targetName)
this-FindErrorMessage = emsg.str();
return;
}
+
+
+int cmCoreTryCompile::CreatePackageAppxmanifestForTest()
+{
+ std::string packageAppxManifestPath = this-BinaryDirectory;
+ packageAppxManifestPath += /Package.appxmanifest;
+
+ FILE *fileout = fopen(packageAppxManifestPath.c_str(), w);
+ if (!fileout)
+ {
+ cmOStringStream e;
+ e Failed to open\n
+ Package.appxmanifest \n
+ cmSystemTools::GetLastSystemError();
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
+ return CREATE_MANIFEST_ERROR;
+ }
+ fprintf(fileout,
+ ?xml version='1.0' encoding='utf-8'?\n
+ Package xmlns='http://schemas.microsoft.com/appx/2010/manifest'\n
+ Identity Name='TestApp'\n
+ Publisher='CN=Cmake.org'\n
+ Version='1.0.0.0' /\n
+ Properties\n
+ DisplayName$targetnametoken$/DisplayName\n
+ PublisherDisplayNameCmake.org/PublisherDisplayName\n
+ LogoImages\\Logo.png/Logo\n
+ DescriptionC++/CX Test application/Description\n
+ /Properties\n
+ Prerequisites\n
+ OSMinVersion6.2/OSMinVersion\n
+ OSMaxVersionTested6.2/OSMaxVersionTested\n
+ /Prerequisites\n
+ Resources\n
+ Resource Language='en-us' /\n
+ /Resources\n
+ Applications\n
+ Application Id='TestID'\n
+ Executable='$targetnametoken$.exe'\n
+ EntryPoint='$targetnametoken$.App'\n
+ VisualElements\n
+ DisplayName='$targetnametoken$'\n
+ Logo='Images\\Logo.png'\n
+ SmallLogo='Images\\SmallLogo.png'\n
+ Description='C++/CX Test application'\n
+ ForegroundText='light'\n
+ BackgroundColor='#22'\n
+ SplashScreen Image='Images\\SplashScreen.png' /\n
+ /VisualElements\n
+ /Application\n
+ /Applications\n
+ /Package);
+ fclose(fileout);
+
+ return CREATE_MANIFEST_OK;
+}
\ No newline at end of file
diff --git a/cmake-2.8.10.2/Source/cmCoreTryCompile.h b/cmake-2.8.10.2/Source/cmCoreTryCompile.h
index 5c67f13..5d52548 100644
--- a/cmake-2.8.10.2/Source/cmCoreTryCompile.h
+++ b/cmake-2.8.10.2/Source/cmCoreTryCompile.h
@@ -14,6 +14,9 @@
#include cmCommand.h
+#define CREATE_MANIFEST_OK 0x00
+#define CREATE_MANIFEST_ERROR 0x01
+
/** \class
Re: [CMake] Binary directory on different drive
Sorry to bump, but any help on this? :) On Fri, Apr 19, 2013 at 6:08 PM, Robert Dailey rcdailey.li...@gmail.com wrote: I am invoking CMake like this on Windows: Working directory is: C:\work\build Directory containing source root level CMakeLists.txt file: Y:\ So I invoke like this: C:\work\build cmake -G NMake Makefiles Y:\ When I do this, any subdirectories I traverse inside Y:\ do not appear under their proper binary directory. Example, let's say I do add_subdirectory to step into library, which is at path Y:\library. The binary directory will be: C:\work\buildlibrary Instead of: C:\work\build\library The slash between build and library is missing. Any reason for this? It doesn't do it if the source binary directories are on the same drive letter. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Generator for the Mac App Store
Does this workflow in your MacAppStore generator include anything that prevents making a .pkg for OS X Installer? From the stackoverlfow link below, the person says App Store submissions follow different rules. Do you know what those differences are? As I've never created an OS X Installer I really don't know. it would be nice to at least start off well and go in the right direction. Agreed. I'm not convinced that an implementation based on the Bundle generator way is the right start. I started with the Bundle generator because that's what I have been using to distribute my application for the last couple of years. Maybe I wasn't clear before. CMake can already do .app creation. I had forgotten that. I had gone with the Bundle generator two years ago because I was able to get it working how I wanted quickly and easily. I based my new generator on it because with the exception of the final dmg vs pkg packaging they should build the same .app folder structure, and I wanted both distribution methods to share the package creation and code signing code. I spend some time this weekend looking at the implementation of the new generator, right now the code signing is in the DragNDrop generator which makes it available for all derived classes, allowing it to be used for both Mac App Store signing, and also for developer code signing required by the default behavior of OS X 10.8 Gatekeeper for non-App Store applications. I would like to hear your thoughts on what you think is the best approach to structuring the code. Thanks, Brian -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Binary directory on different drive
On 04/19/2013 07:08 PM, Robert Dailey wrote: C:\work\buildlibrary Instead of: C:\work\build\library The slash between build and library is missing. Any reason for this? It doesn't do it if the source binary directories are on the same drive letter. Almost certainly this is: http://www.cmake.org/Bug/view.php?id=10072 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1df49282 Please try 2.8.11-rc2. -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Binary directory on different drive
Awesome!! I just tried RC3 and it works now. Great job On Mon, Apr 22, 2013 at 10:54 AM, Brad King brad.k...@kitware.com wrote: On 04/19/2013 07:08 PM, Robert Dailey wrote: C:\work\buildlibrary Instead of: C:\work\build\library The slash between build and library is missing. Any reason for this? It doesn't do it if the source binary directories are on the same drive letter. Almost certainly this is: http://www.cmake.org/Bug/view.php?id=10072 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1df49282 Please try 2.8.11-rc2. -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://www.cmake.org/mailman/listinfo/cmake
[CMake] Cross compile an external makefile project.
I have a project to port to the raspberry pi.
I managed to get boost to cross-compile with the externalproject_Add on windows
and am trying to do something similar with curl.
Because curl uses make and not bjam, I switched over to a linux build agent but
I am having difficulty.
Everything seems good at the beginning, it detects my compiler and the linux
build but then before the un-tar stage it says changes have been made that
require restarting cmake and it then fails to detect the compiler and stops.
Cmake is 2.8.7 on Ubuntu build image.
Is there an example of combining cross-compiling with an externalProject_add.
{There are a lot of options for a trial and error technique, I am getting tired
of guessing :)}
BTW. Does it set and pass CC variables and prefixes that are in the cmake
settings or do I have to manually pass them like I did with bjam.
Thanks.
Jeff Shanab, Manager-Software Engineering
D 630.633.4515 | C 630.453.7764 | F 630.633.4815 |
jsha...@smartwire.commailto:jsha...@smartwire.com
[MVSSig]
This message and any attachments contain confidential and proprietary
information, and may contain privileged information, belonging to one or more
affiliates of Windy City Wire Cable Technology Products, LLC. No privilege is
waived by this transmission. Unauthorized use, copying or disclosure of such
information is prohibited and may be unlawful. If you receive this message in
error, please delete it from your system, destroy any printouts or copies of
it, and notify the sender immediately by e-mail or phone.
inline: image001.gif--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Excluding targets from a solution config in a Visual Studio build
Hi there Is there a way to tell the Visual Studio generators that a target should not be included in “whole solution” builds? With the following sequence A will be excluded from all solution configurations, but B will be included. add_custom_target(A) add_custom_target(B COMMAND echo This is target B) add_dependencies(A B) I’m actually trying to define a set of targets that do not get built automatically when one does a “solution build” in Visual Studio. I.e. I’d like to find a way to have B excluded as well. Is this possible at all? Thanks in advance! And thanks to the CMake folks for the great tool! -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Sharing sources between two targets
Folks, I am using CMake to create 2 targets - a stand-alone executable and a library that can be imported by Python. Both share most of the sources. If I just specify them as two separate targets, each will compile all the sources, so most of the source files end up compiled twice. Is there a way to share the compiled sources between the two targets? I can create an intermediate library, but that is less convenient since the executable will then depend on it. What I would really like is to have a self-contained executable and a separate library that use the same object files. Many thanks for any hint, Nick Gnedin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
Hi Nick, What about creating a static library that would be linked against both the executable and the library ? Hth Jc On Mon, Apr 22, 2013 at 2:45 PM, Nick Gnedin ngne...@gmail.com wrote: Folks, I am using CMake to create 2 targets - a stand-alone executable and a library that can be imported by Python. Both share most of the sources. If I just specify them as two separate targets, each will compile all the sources, so most of the source files end up compiled twice. Is there a way to share the compiled sources between the two targets? I can create an intermediate library, but that is less convenient since the executable will then depend on it. What I would really like is to have a self-contained executable and a separate library that use the same object files. Many thanks for any hint, Nick Gnedin -- 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 -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
A static lib does what you want and won't introduce any extra runtime dependecies On 22 Apr 2013 19:45, Nick Gnedin ngne...@gmail.com wrote: Folks, I am using CMake to create 2 targets - a stand-alone executable and a library that can be imported by Python. Both share most of the sources. If I just specify them as two separate targets, each will compile all the sources, so most of the source files end up compiled twice. Is there a way to share the compiled sources between the two targets? I can create an intermediate library, but that is less convenient since the executable will then depend on it. What I would really like is to have a self-contained executable and a separate library that use the same object files. Many thanks for any hint, Nick Gnedin -- 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
That doubles the size of the executable, because if I do something like
that:
ADD_LIBRARY(temp STATIC ${sources})
TARGET_LINK_LIBRARIES(temp outside_deps)
ADD_EXECUTABLE(code main.cpp)
TARGET_LINK_LIBRARIES(code temp)
then TARGET_LINK_LIBRARIES(...) also add outside_deps as link libraries
for code, so they end up included twice.
On 04/22/2013 01:50 PM, Jean-Christophe Fillion-Robin wrote:
Hi Nick,
What about creating a static library that would be linked against both
the executable and the library ?
Hth
Jc
On Mon, Apr 22, 2013 at 2:45 PM, Nick Gnedin ngne...@gmail.com
mailto:ngne...@gmail.com wrote:
Folks,
I am using CMake to create 2 targets - a stand-alone executable and
a library that can be imported by Python. Both share most of the
sources. If I just specify them as two separate targets, each will
compile all the sources, so most of the source files end up compiled
twice.
Is there a way to share the compiled sources between the two
targets? I can create an intermediate library, but that is less
convenient since the executable will then depend on it. What I would
really like is to have a self-contained executable and a separate
library that use the same object files.
Many thanks for any hint,
Nick Gnedin
--
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/__opensource/opensource.html
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
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/__listinfo/cmake
http://www.cmake.org/mailman/listinfo/cmake
--
+1 919 869 8849
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
Nick Gnedin wrote:
That doubles the size of the executable, because if I do something like
that:
ADD_LIBRARY(temp STATIC ${sources})
TARGET_LINK_LIBRARIES(temp outside_deps)
ADD_EXECUTABLE(code main.cpp)
TARGET_LINK_LIBRARIES(code temp)
then TARGET_LINK_LIBRARIES(...) also add outside_deps as link libraries
for code, so they end up included twice.
You can't link anything into a static library, so it will end up being linked
in only once anyway.
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
No, it doesn't double anything.
Without the outside_deps, the executable wouldn't link if it needed
something from them.
With them, it will link, and be as small a size as the linker can make
it. (Assuming a release build, where the linker leaves out what it
doesn't need...)
-Original Message-
From: Nick Gnedin ngne...@gmail.com
Cc: CMake ML cmake@cmake.org
Sent: Mon, Apr 22, 2013 2:55 pm
Subject: Re: [CMake] Sharing sources between two targets
That doubles the size of the executable, because if I do something like
that:
ADD_LIBRARY(temp STATIC ${sources})
TARGET_LINK_LIBRARIES(temp outside_deps)
ADD_EXECUTABLE(code main.cpp)
TARGET_LINK_LIBRARIES(code temp)
then TARGET_LINK_LIBRARIES(...) also add outside_deps as link libraries
for code, so they end up included twice.
On 04/22/2013 01:50 PM, Jean-Christophe Fillion-Robin wrote:
Hi Nick,
What about creating a static library that would be linked against both
the executable and the library ?
Hth
Jc
On Mon, Apr 22, 2013 at 2:45 PM, Nick Gnedin ngne...@gmail.com
mailto:ngne...@gmail.com wrote:
Folks,
I am using CMake to create 2 targets - a stand-alone executable
and
a library that can be imported by Python. Both share most of the
sources. If I just specify them as two separate targets, each will
compile all the sources, so most of the source files end up
compiled
twice.
Is there a way to share the compiled sources between the two
targets? I can create an intermediate library, but that is less
convenient since the executable will then depend on it. What I
would
really like is to have a self-contained executable and a separate
library that use the same object files.
Many thanks for any hint,
Nick Gnedin
--
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/__opensource/opensource.html
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
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/__listinfo/cmake
http://www.cmake.org/mailman/listinfo/cmake
--
+1 919 869 8849
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
Indeed everything works that way, many thanks, guys.
On 04/22/2013 02:09 PM, David Cole wrote:
No, it doesn't double anything.
Without the outside_deps, the executable wouldn't link if it needed
something from them.
With them, it will link, and be as small a size as the linker can make
it. (Assuming a release build, where the linker leaves out what it
doesn't need...)
-Original Message-
From: Nick Gnedin ngne...@gmail.com
Cc: CMake ML cmake@cmake.org
Sent: Mon, Apr 22, 2013 2:55 pm
Subject: Re: [CMake] Sharing sources between two targets
That doubles the size of the executable, because if I do something like
that:
ADD_LIBRARY(temp STATIC ${sources})
TARGET_LINK_LIBRARIES(temp outside_deps)
ADD_EXECUTABLE(code main.cpp)
TARGET_LINK_LIBRARIES(code temp)
then TARGET_LINK_LIBRARIES(...) also add outside_deps as link libraries
for code, so they end up included twice.
On 04/22/2013 01:50 PM, Jean-Christophe Fillion-Robin wrote:
Hi Nick,
What about creating a static library that would be linked against both
the executable and the library ?
Hth
Jc
On Mon, Apr 22, 2013 at 2:45 PM, Nick Gnedin ngne...@gmail.com
mailto:ngne...@gmail.com wrote:
Folks,
I am using CMake to create 2 targets - a stand-alone executable
and
a library that can be imported by Python. Both share most of the
sources. If I just specify them as two separate targets, each will
compile all the sources, so most of the source files end up
compiled
twice.
Is there a way to share the compiled sources between the two
targets? I can create an intermediate library, but that is less
convenient since the executable will then depend on it. What I
would
really like is to have a self-contained executable and a separate
library that use the same object files.
Many thanks for any hint,
Nick Gnedin
--
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/__opensource/opensource.html
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
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/__listinfo/cmake
http://www.cmake.org/mailman/listinfo/cmake
--
+1 919 869 8849
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sharing sources between two targets
to use the same sources in multiple outputs, with different compile
options, I make a copy of the file (copy_if_different) into the binary, and
then specify that for the related projects.
EXECUTE_PROCESS(COMMAND cmake -E copy_if_different
${CMAKE_SOURCE_DIR}/${VECTLIB_SOURCES}
${CMAKE_BINARY_DIR}/src/vectlib/vectlib_double.cpp )
it's quite happy to make any missing path parts... can do something to
extract original path parts so you can make it be a similar relative path
in the binary.
On Mon, Apr 22, 2013 at 11:45 AM, Nick Gnedin ngne...@gmail.com wrote:
Folks,
I am using CMake to create 2 targets - a stand-alone executable and a
library that can be imported by Python. Both share most of the sources. If
I just specify them as two separate targets, each will compile all the
sources, so most of the source files end up compiled twice.
Is there a way to share the compiled sources between the two targets? I
can create an intermediate library, but that is less convenient since the
executable will then depend on it. What I would really like is to have a
self-contained executable and a separate library that use the same object
files.
Many thanks for any hint,
Nick Gnedin
--
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
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Install target after building it
I want to setup a target's header files to be copied to a separate directory after that target is built. Any dependent targets will reference the INSTALLED header files, so they must be copied after that target is built and prior to any other targets (that depend on it) that get built. Is there a way to do this? Right now I use INSTALL( FILES ) but this isn't target-specific. Thanks. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Sublime Text 2
Is anyone using Sublime Text 2: http://www.sublimetext.com/2. If so, do you know of, or can recommend a good CMake syntax highlighter? It seems to be a really useful cross-platform text editor that is consistent and easily customisable. Regards Andrew -- ___ Andrew J. P. Maclean ___ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Install target after building it
On 2013-04-22 18:12, Robert Dailey wrote: I want to setup a target's header files to be copied to a separate directory after that target is built. Any dependent targets will reference the INSTALLED header files, so they must be copied after that target is built and prior to any other targets (that depend on it) that get built. Is there a way to do this? Right now I use INSTALL( FILES ) but this isn't target-specific. Thanks. I do something similar, although I wouldn't recommend using INSTALL as it requires re-running CMake any time you change a header. What I do is have a function that takes a list of public headers, create a target e.g. myLibrary-headers with custom commands to copy the headers as needed (i.e. a copy command per header that depends on the original header), and then make myLibrary depend on this target. -- Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Install target after building it
On 2013-04-22 19:46, Matthew Woehlke wrote: On 2013-04-22 18:12, Robert Dailey wrote: I want to setup a target's header files to be copied to a separate directory after that target is built. Any dependent targets will reference the INSTALLED header files, so they must be copied after that target is built and prior to any other targets (that depend on it) that get built. Is there a way to do this? Right now I use INSTALL( FILES ) but this isn't target-specific. Thanks. I do something similar, although I wouldn't recommend using INSTALL as it requires re-running CMake any time you change a header. Actually I'm not sure why I said that... it's wrong :-). Two problems with install are 1: requires writable install directory (which is not guaranteed to be the case for other users), and 2: requires running all other install logic. (And 3: is not target specific, as you noted.) -- Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [Cmake-commits] cmake vsArm support patch
On 04/22/2013 08:23 AM, Igor Novikov wrote: I’ve developed patch for Visual Studio ARM support. (Patch file is attached) I'd like you to try patch functionality and get a review. http://public.kitware.com/Bug/view.php?id=13511 This is a commit notification list. Please raise this on the user list: http://www.cmake.org/mailman/listinfo/cmake -Brad ___ 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.10.2-2813-g8ca1498
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 8ca149896566119be4d324fd56cbe66d755b8d9e (commit)
via eb0d1aee41a81a18823d2c4c436663c595f4e3d8 (commit)
from f988603bc6f15b9c9553653135b691343f5647c1 (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=8ca149896566119be4d324fd56cbe66d755b8d9e
commit 8ca149896566119be4d324fd56cbe66d755b8d9e
Merge: f988603 eb0d1ae
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Mon Apr 22 15:51:53 2013 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Apr 22 15:51:53 2013 -0400
Merge topic 'refs/heads/QtDialogSearchText2' into next
eb0d1ae QtDialog: fix build with Qt 4.4
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb0d1aee41a81a18823d2c4c436663c595f4e3d8
commit eb0d1aee41a81a18823d2c4c436663c595f4e3d8
Author: Alex Neundorf neund...@kde.org
AuthorDate: Mon Apr 22 21:51:33 2013 +0200
Commit: Alex Neundorf neund...@kde.org
CommitDate: Mon Apr 22 21:51:33 2013 +0200
QtDialog: fix build with Qt 4.4
Don't use QStringList::remoevDuplicates(), new in 4.5
Alex
diff --git a/Source/QtDialog/CMakeSetupDialog.cxx
b/Source/QtDialog/CMakeSetupDialog.cxx
index 31e89cb..4d62f72 100644
--- a/Source/QtDialog/CMakeSetupDialog.cxx
+++ b/Source/QtDialog/CMakeSetupDialog.cxx
@@ -1208,8 +1208,10 @@ void CMakeSetupDialog::doOutputFindDialog()
tr(Find:), strings, 0, true, ok);
if (ok !search.isEmpty())
{
-this-FindHistory.push_front(search);
-this-FindHistory.removeDuplicates();
+if (!this-FindHistory.contains(search))
+ {
+ this-FindHistory.push_front(search);
+ }
doOutputFindNext();
}
}
---
Summary of changes:
Source/QtDialog/CMakeSetupDialog.cxx |6 --
1 files changed, 4 insertions(+), 2 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.10.2-1003-g2baf851
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 2baf851c34357cbb752bb91b99b835d3847b23a1 (commit) from e55b8ce4a4f5d6a935fe82d600637c79e64e8cbd (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=2baf851c34357cbb752bb91b99b835d3847b23a1 commit 2baf851c34357cbb752bb91b99b835d3847b23a1 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Apr 23 00:01:07 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Apr 23 00:01:07 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 8929d91..8c4f471 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 10) -set(CMake_VERSION_TWEAK 20130422) +set(CMake_VERSION_TWEAK 20130423) #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
