[cmake-developers] [CMake 0013843]: FindMPI doesn't set MPI_C_LINK_FLAGS or MPI_C_COMPILE_FLAGS (and same for CXX)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13843
==
Reported By:jgu
Assigned To:
==
Project:CMake
Issue ID: 13843
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-01-10 07:01 EST
Last Modified: 2013-01-10 07:01 EST
==
Summary:FindMPI doesn't set MPI_C_LINK_FLAGS or
MPI_C_COMPILE_FLAGS (and same for CXX)
Description:
I have a project which does a find_package(MPI). I use the following snippet to
print out all variables:
get_cmake_property(_variableNames VARIABLES)
foreach (_variableName ${_variableNames})
message(STATUS ${_variableName}=${${_variableName}})
endforeach()
which produces for the MPI relevant variables:
-- MPIEXEC=/usr/lib64/openmpi/bin/mpiexec
-- MPIEXEC_MAX_NUMPROCS=2
-- MPIEXEC_NUMPROC_FLAG=-np
-- MPIEXEC_POSTFLAGS=
-- MPIEXEC_PREFLAGS=
-- MPI_COMPILER=/usr/lib64/openmpi/bin/mpicxx
-- MPI_COMPILER_IS_EXECUTABLE=0
-- MPI_CXX_COMPILER=/usr/lib64/openmpi/bin/mpicxx
-- MPI_CXX_COMPILE_FLAGS=
-- MPI_CXX_FOUND=TRUE
-- MPI_CXX_INCLUDE_PATH=/usr/include/openmpi-x86_64
--
MPI_CXX_LIBRARIES=/usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_CXX_LINK_FLAGS=
-- MPI_C_COMPILER=/usr/lib64/openmpi/bin/mpicc
-- MPI_C_COMPILE_FLAGS=
-- MPI_C_FOUND=TRUE
-- MPI_C_INCLUDE_PATH=/usr/include/openmpi-x86_64
-- MPI_C_LIBRARIES=/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_C_LINK_FLAGS=
-- MPI_EXTRA_LIBRARY=/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_EXTRA_LIBRARY_WORK=/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_FOUND=TRUE
-- MPI_HEADER_PATH=MPI_HEADER_PATH-NOTFOUND
-- MPI_INCLUDE_PATH=/usr/include/openmpi-x86_64
-- MPI_LIB=MPI_LIB-NOTFOUND
--
MPI_LIBRARIES=/usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so
-- MPI_LIBRARY=/usr/lib64/openmpi/lib/libmpi_cxx.so
-- MPI_LIBRARY_WORK=/usr/lib64/openmpi/lib/libmpi_cxx.so
-- MPI_NUMLIBS=3
-- MpiPackageDir=
which shows empty MPI_C_LINK_FLAGS and MPI_C_COMPILE_FLAGS and the same for the
equivalent CXX variables. As a result, even though my project has this:
set_target_properties(myexec PROPERTIES
COMPILE_FLAGS ${MPI_C_COMPILE_FLAGS}
COMPILE_DEFINITIONS BUILD_WITH_MPI
LINK_FLAGS ${MPI_C_LINK_FLAGS}
)
it fails to link against mpi (-lmpi is missing, for a start).
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-10 07:01 jguNew 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 0013844]: PurifyPlus 7.0.1-003 cannot properly interpret SAVETEXTDATA command line switch due to quotation marks
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13844 == Reported By:Ingmar Voigt Assigned To: == Project:CMake Issue ID: 13844 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-01-10 07:29 EST Last Modified: 2013-01-10 07:29 EST == Summary:PurifyPlus 7.0.1-003 cannot properly interpret SAVETEXTDATA command line switch due to quotation marks Description: PROBLEM: This started with PurifyPlus 7.0.1-003 - PurifyPlus 7.0.0 did not show such behaviour. The solution should however work for both CTest 2.8.3 memchecker produces on Windows the following command line to execute Purify (extracted from my logs): C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log D:/MyBinDir/bin/Debug/MyTest.exe When executing this Purify 7.0.1-003 complains the following way: Unable to find file /SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log. The reason is the command line /SAVETEXTDATA=... is wrapped in quotation marks /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log the problem does not occur when changing the command line by shift the quotation mark after the equal sign: /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log SOLUTION: use /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log instead of /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log i.e. C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log D:/MyBinFolder/bin/Debug/MyTest.exe Steps to Reproduce: Execute PurifyPlus 7.0.1-003 C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log D:/MyBinFolder/bin/Debug/MyTest.exe and try again with C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA=D:/MyBinFolder/Testing/Temporary/MemoryChecker.log D:/MyBinFolder/bin/Debug/MyTest.exe Additional Information: From the CTest logs: Memory check command: C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log 149: MemCheck command: C:\Progra~1\IBM\RationalPurifyPlus\purify.exe /SAVETEXTDATA=D:/MyBinDir/Testing/Temporary/MemoryChecker.log D:/MyBinDir/bin/Debug/MyTest.exe == Issue History Date ModifiedUsername FieldChange == 2013-01-10 07:29 Ingmar Voigt 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
[cmake-developers] CPACK_RESOURCE_FILE_LICENSE character encoding
Is a license text file pointed to by CPACK_RESOURCE_FILE_LICENSE expected to have a specific encoding (ASCII, Latin1, UTF-8, ...)? Nils -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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] CPACK_RESOURCE_FILE_LICENSE character encoding
2013/1/10 Nils Gladitz glad...@sci-vis.de: Is a license text file pointed to by CPACK_RESOURCE_FILE_LICENSE expected to have a specific encoding (ASCII, Latin1, UTF-8, ...)? I don't know but I bet that some encoding may be accepted by some CPack generator and poorly handled by others. CPACK_RESOURCE_FILE_LICENSE is used by: STGZ WIX DragNDrop PackageMaker NSIS WIX has documentation about that: see cpack --help-variable CPACK_WIX_LICENSE_RTF For the other generators I bet ASCII should work other encoding may work. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CPACK_RESOURCE_FILE_LICENSE character encoding
I wrote the WiX part and am pondering how to support extended character sets without having to provide an extra RTF file. We've got an english license text file but our company address still contains a german umlaut. I could provide an RTF but I'd prefer not to have two license files. Nils On 01/10/2013 03:41 PM, Eric Noulard wrote: 2013/1/10 Nils Gladitz glad...@sci-vis.de: Is a license text file pointed to by CPACK_RESOURCE_FILE_LICENSE expected to have a specific encoding (ASCII, Latin1, UTF-8, ...)? I don't know but I bet that some encoding may be accepted by some CPack generator and poorly handled by others. CPACK_RESOURCE_FILE_LICENSE is used by: STGZ WIX DragNDrop PackageMaker NSIS WIX has documentation about that: see cpack --help-variable CPACK_WIX_LICENSE_RTF For the other generators I bet ASCII should work other encoding may work. -- Nils Gladitz, B.Sc. DICOM, Konnektivität und Entwicklung Scivis wissenschaftliche Bildverarbeitung GmbH Bertha-von-Suttner-Str. 5 D-37085 Göttingen GERMANY Handelsregister Nr. / Trade Register No. B3100 Göttingen Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr. Uwe Engeland Tel: 0049 (0)551 634181-28 E-Mail: glad...@scivis.de Web: www.scivis.de -- 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] LINK_INTERFACE_LIBRARIES-genex topic review
Steve, While reviewing this topic I ran the ExportImport test to look for generator expressions in a link interface property. I do not see any. The test C++ code appears to verify that libraries are linked but it is compiled into a static library as added by this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=894f52f3#patch7 Therefore it never really links. If I change add_library to add_executable then the test fails with /usr/bin/ld: cannot find -ltestLibsDepends If I fix the typo (s/Libs/Lib/) then it fails with deps_iface.cpp:(.text+0x11): undefined reference to `testLibDepends()' deps_iface.cpp:(.text+0x1f): undefined reference to `TestLibLibraryRequired::foo()' because the library is not actually linked. Please take a look. Thanks, -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] [CMake 0013842]: No Support for C++11
Eike, On 01/09/2013 11:02 AM, Dave Abrahams wrote: http://www.cmake.org/Bug/view.php?id=13842 == We could use C++11 feature detection per http://pageant.ghulbus.eu/?p=664 This picks up from the C++0x patch you posted here: http://www.cmake.org/pipermail/cmake/2011-March/043575.html but renames it to C++11 now that it is out. If you have time please take a look at integrating the feature checks upstream. IMO the test C++ source files should be named Modules/Cxx11/test-*.cpp instead of files with '+' in their name directly in Modules/. Thanks, -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] [CMake 0013842]: No Support for C++11
Am 10.01.2013 16:40, schrieb Brad King: Eike, On 01/09/2013 11:02 AM, Dave Abrahams wrote: http://www.cmake.org/Bug/view.php?id=13842 == We could use C++11 feature detection per http://pageant.ghulbus.eu/?p=664 This picks up from the C++0x patch you posted here: http://www.cmake.org/pipermail/cmake/2011-March/043575.html but renames it to C++11 now that it is out. If you have time please take a look at integrating the feature checks upstream. IMO the test C++ source files should be named Modules/Cxx11/test-*.cpp instead of files with '+' in their name directly in Modules/. As I already wrote in a comment on that blog I have the current version of my code here: git clone git://anongit.kde.org/scratch/dakon/cmake-cxx11 Everyone interested please look there and send me patches/suggestions/bugreports/pizza/alcohol... 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CPACK_RESOURCE_FILE_LICENSE character encoding
2013/1/10 Nils Gladitz glad...@sci-vis.de: I wrote the WiX part and am pondering how to support extended character sets without having to provide an extra RTF file. Sorry I did not connect the dots. We've got an english license text file but our company address still contains a german umlaut. Yes I'm french and we do have a bunch of non-ascii characters as well (including french trema which is just like umlaut) but we currently avoid those since none of them appear in our address :-] I could provide an RTF but I'd prefer not to have two license files. I think the best way to go would be to try to go for utf-8 encoding which is relatively widespread nowadays and goes into testing for each CPack generator which currently use CPACK_RESOURCE_FILE_LICENSE. Reading/writing utf-8 seems doable in plain C++ without an example (untested) here: http://utfcpp.sourceforge.net/ -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] LINK_INTERFACE_LIBRARIES-genex topic review
Brad King wrote: Steve, While reviewing this topic I ran the ExportImport test to look for generator expressions in a link interface property. I do not see any. The test C++ code appears to verify that libraries are linked but it is compiled into a static library as added by this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=894f52f3#patch7 Therefore it never really links. If I change add_library to add_executable then the test fails with /usr/bin/ld: cannot find -ltestLibsDepends If I fix the typo (s/Libs/Lib/) then it fails with deps_iface.cpp:(.text+0x11): undefined reference to `testLibDepends()' deps_iface.cpp:(.text+0x1f): undefined reference to `TestLibLibraryRequired::foo()' because the library is not actually linked. Please take a look. Thanks for trying it. I get the same linking error after applying the typo fix and the change to add_executable on master. After cd Import/A in the build dir, and make VERBOSE=1, I get this: /usr/lib/icecc/bin/c++ -gCMakeFiles/deps_iface.dir/deps_iface.cpp.o - o deps_iface -rdynamic /home/stephen/dev/src/cmake/Tests/ExportImport/build/Root/lib/libtestLibDepends.a /home/stephen/dev/src/cmake/Tests/ExportImport/build/Root/lib/libtestLibRequired.a so it seems that the libraries are being passed to the linker, but the symbols are not being resolved? I haven't yet seen why that is. Any ideas? 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] LINK_INTERFACE_LIBRARIES-genex topic review
Stephen Kelly wrote: so it seems that the libraries are being passed to the linker, but the symbols are not being resolved? I haven't yet seen why that is. Any ideas? The problem was that I was creating a CXX executable without using extern C. I've pushed a branch to fix it, but haven't merged it to next yet. Will I do so? I'll add another proper test for the shared library with IMPORTED_LINK_INTERFACE_LIBRARIES generator expressions case. 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] LINK_INTERFACE_LIBRARIES-genex topic review
On 01/10/2013 11:17 AM, Stephen Kelly wrote: The problem was that I was creating a CXX executable without using extern C. I've pushed a branch to fix it, but haven't merged it to next yet. Will I do so? Yes, please. Then rebase the link interface topic on it so the test covers what we expect. Thanks, -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] LINK_INTERFACE_LIBRARIES-genex topic review
Brad King wrote: On 01/10/2013 11:17 AM, Stephen Kelly wrote: The problem was that I was creating a CXX executable without using extern C. I've pushed a branch to fix it, but haven't merged it to next yet. Will I do so? Yes, please. Then rebase the link interface topic on it so the test covers what we expect. Done now. 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] [CMake 0013842]: No Support for C++11
I would prefer a more compicated variadic template test that exercises
variadic code such as:
templatetypename G = void, typename H = void
struct foo
{};
templatetypename... G
struct bar : fooG...
{};
int main() {
barint, float f;
}
So that we detect compilers like gcc 4.6 that supported the initial
variadic specification, and not the updated specification.
On Thu, Jan 10, 2013 at 10:49 AM, Rolf Eike Beer e...@sf-mail.de wrote:
git://anongit.kde.org/scratch/**dakon/cmake-cxx11http://anongit.kde.org/scratch/dakon/cmake-cxx11
--
Robert Maynard
--
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] Compatible INTERFACE user properties and string properties
Now that the INTERFACE_PIC branch is in, the next topic I have in that line is the compatible-INTERFACE-user-properties topic I've just pushed to gitorious. Because I'll be automatically linking the Qt4::qtmain library into executables which are WIN32_EXECUTABLEs, and because QtActiveX requires that Qt4::qtmain is not linked in to executables, I need some way to enforce that. My solution is to check the QT4_NO_LINK_QTMAIN in the generator expression which links in Qt4::qtmain, and to set INTERFACE_QT4_NO_LINK_QTMAIN to OFF in the QtActiveX library. On its own, that has no effect, but the compatible-INTERFACE-user-properties topic allows us to use the same logic as is used for the PIC feature to implement that, if the user code populates the COMPATIBLE_INTERFACE_BOOL property: set_property(TARGET Qt4::QAxServer APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL QT4_NO_LINK_QTMAIN) I think that I can add some API to cmPropertyDefinitionMap via the cmake instance to ensure that built-in properties can not be used in that property. The topic is also missing documentation currently. I wanted to get feedback on the approach first. Secondly, I've pushed the INTERFACE_PROPERTIES branch again. This topic is not something that I'd like to get into master soon, but something I thought I'd bring up. It generalizes the logic introduced in the INTERFACE_PIC topic to also be able to require 'equal strings', not only 'truthiness equal booleans'. The reason for that is that I was thinking of C++11 support and how clang can be used with different stdlib implementations, -stdlib=libc++ or - stdlib=libstdc++. The two are obviously not compatible, and a library using one should not be linked with a library using the other. Additionally, an executable using a library build with -stdlib=libc++ should also use libc++ itself. This is very similar to the PIC situation, and is something we could implement support in CMake for. For example, setting the CXX_STDLIB property on a target to libc++ would pass -stdlib=libc++ if using clang. What it does for other compilers is up for debate. Linking a target to a library with INTERFACE_CXX_STDLIB=libc++ would set the CXX_STDLIB property on the target libc++ too etc, and un-equal strings in that property would be a generate- time error. If built into CMake as a feature, we would probably need to also handle other stl implementations like libstdc++-v2 libstdc++-v3, eastl, ustl, stlport etc and treat other strings as errors. Similar to my first point above, this string equality requirement could also be extended to users with a COMPATIBLE_INTERFACE_STRING property. That would allow for example to set QT_SOVERSION to 4 on Qt4::QtCore and to 5 on Qt5::Core, so that a generate-time error is hit if they are accidentally used together. What do you think? 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] Compatible INTERFACE user properties and string properties
On 01/10/2013 01:04 PM, Stephen Kelly wrote: the COMPATIBLE_INTERFACE_BOOL property: set_property(TARGET Qt4::QAxServer APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL QT4_NO_LINK_QTMAIN) A better name may be INTERFACE_COMPATIBLE_BOOL since the compatibility requirement is actually part of the interface. Actually, since you made generator expressions use lazy evaluation, can't we introduce a $FATAL_ERROR:msg expression that could be used inside some condition checker to report failure? implement support in CMake for. For example, setting the CXX_STDLIB property on a target to libc++ would pass -stdlib=libc++ if using clang. What it does for other compilers is up for debate. Linking a target to a library with INTERFACE_CXX_STDLIB=libc++ would set the CXX_STDLIB property on the target libc++ too etc, and un-equal strings in that property would be a generate- time error. [snip] Similar to my first point above, this string equality requirement could also be extended to users with a COMPATIBLE_INTERFACE_STRING property. Yes, this sounds promising for solving problems like that. Thanks, -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] CPACK_RESOURCE_FILE_LICENSE character encoding
Yes, I think I'd prefer UTF-8 as well. Unless most of the other generators use something else or there is a contradicting convention or preference for CMake/CPack? I guess I'll try running some license files through some of the generators that you listed and see what comes out. Thank you for your input! Nils On 01/10/2013 04:55 PM, Eric Noulard wrote: 2013/1/10 Nils Gladitz glad...@sci-vis.de: I wrote the WiX part and am pondering how to support extended character sets without having to provide an extra RTF file. Sorry I did not connect the dots. We've got an english license text file but our company address still contains a german umlaut. Yes I'm french and we do have a bunch of non-ascii characters as well (including french trema which is just like umlaut) but we currently avoid those since none of them appear in our address :-] I could provide an RTF but I'd prefer not to have two license files. I think the best way to go would be to try to go for utf-8 encoding which is relatively widespread nowadays and goes into testing for each CPack generator which currently use CPACK_RESOURCE_FILE_LICENSE. Reading/writing utf-8 seems doable in plain C++ without an example (untested) here: http://utfcpp.sourceforge.net/ -- 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 0013845]: CMake segfault if extra newline in link.txt
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13845
==
Reported By:rbmj
Assigned To:
==
Project:CMake
Issue ID: 13845
Category: (No Category)
Reproducibility:always
Severity: crash
Priority: normal
Status: new
==
Date Submitted: 2013-01-10 15:12 EST
Last Modified: 2013-01-10 15:12 EST
==
Summary:CMake segfault if extra newline in link.txt
Description:
The origin of this problem was that I was writing/testing a cross toolchain file
which made complicated custom link rules. One of the variables in the link rule
came from an execute_process command that had a trailing newline and that,
because of its positioning, ended up adding a blank line in the link.txt. This
causes cmake to segfault.
This may be rare enough that it's not an issue. Also, I don't have the latest
and greatest CMake, so it may already be fixed...
Reproducing is easy though:
Steps to Reproduce:
Make hello.c:
#include stdio.h
int main() {
printf(Hello, World!\n);
return 0;
}
and CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
project(hello)
add_executable(hello hello.c)
Go to build directory and run cmake. Then, add a blank line to the beginning of
CMakeFiles/hello.dir/link.txt
Run make:
...
Linking C executable hello
Error running link command: Segmentation fault
make[2]: *** [hello] Error 1
make[1]: *** [CMakeFiles/hello.dir/all] Error 2
make: *** [all] Error 2
==
Issue History
Date ModifiedUsername FieldChange
==
2013-01-10 15:12 rbmj 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] Compatible INTERFACE user properties and string properties
Brad King wrote: On 01/10/2013 01:04 PM, Stephen Kelly wrote: the COMPATIBLE_INTERFACE_BOOL property: set_property(TARGET Qt4::QAxServer APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL QT4_NO_LINK_QTMAIN) A better name may be INTERFACE_COMPATIBLE_BOOL since the compatibility requirement is actually part of the interface. Perhaps. I chose COMPATIBLE_INTERFACE_BOOL because it is not INTERFACE_*, which would imply a different convention. If you have no better compromise, I'm happy with either. Actually, since you made generator expressions use lazy evaluation, can't we introduce a $FATAL_ERROR:msg expression that could be used inside some condition checker to report failure? Yes, that sounds like a good idea. implement support in CMake for. For example, setting the CXX_STDLIB property on a target to libc++ would pass -stdlib=libc++ if using clang. What it does for other compilers is up for debate. Linking a target to a library with INTERFACE_CXX_STDLIB=libc++ would set the CXX_STDLIB property on the target libc++ too etc, and un-equal strings in that property would be a generate- time error. [snip] Similar to my first point above, this string equality requirement could also be extended to users with a COMPATIBLE_INTERFACE_STRING property. Yes, this sounds promising for solving problems like that. Great. 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] Cmake absolute paths with gcc, __FILE__ , and logging
2013/1/7 Willy Lambert lambert.wi...@gmail.com: really sorry, last mail was sent too early X-( 2013/1/7 Willy Lambert lambert.wi...@gmail.com: 2013/1/4 Andreas Mohr a...@lisas.de: Hi, On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-requ...@cmake.org wrote: Date: Fri, 4 Jan 2013 16:58:05 +0100 From: Willy Lambert lambert.wi...@gmail.com Hi all, Short Story : I am trying to convert an existing project from Manual Makefiles to Cmake for building it. We have a logger that rely on the __FILE__ define to say which file is writing into the log but this is broken by the CMake default behavior using absolute paths. So I wonder if there is any way to have the file name in the code to be able to log Error : line XXX in file.cpp. Long Story : So I have for instance a source /home/me/src/main.cpp, compiled with relative paths gcc -o main.cpp. So the logger say Error : line XXX in main.cpp. I'm afraid given the discussion at Short form of __FILE__ http://bytes.com/topic/c/answers/453661-short-form-__file__ the onus is on your project since it seems to be relying on seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro (compilers seem to be free to pass on either a file's basename only or a relative path or even a FQPN). Depends what you listen under standard. In my case it's standrd with GNU tools. If you know how I could log filename + line number in a standardized way let me know (or point links), I'll be very happy for that. For now, I'm only expected my project working with GNU, and only it (which is rather by necessity than by choice). And now that one is using a CMake build which needs to do builds from an entirely separate binary tree referencing source files in a foreign source tree (thus having a justified reason for needing to specify paths in full), Yes and no. Yes, CMake has to manage a source root dir and a binary output dir (and maybe a relative path from source to build ?), but I'm not sure that you *need* it to build (see the CMAKE_USE_RELATIVE_PATHS option that is already working on simple cases). In my case, it's a classical CMake tructure : myproject/ build src so I understand that cmake has to know about internal src/build structure (and I wouldn't mind cmake using src/XXX path without being able to prevent the src particule which is not a problem). What I don't want is having information in my binaries about my myproject folder location. So it's a strong reason in current implementation, not sure it is justified. Nevertheless I'm aware that as all free project it has limitation, lack of contributions, etc, ... what I mean is that I'm not sure that the onus of this is *only* my project. I have 3 solutions (in this order of priority) : _ extending Cmake _ finding a hack _ changing log system (for an obvious reason you can't switch easily an existing project regarding log because there are lot of work to do) these improper assumptions in your project seem to fall flat on their face, since gcc chooses to prefer to pass on as much information to the __FILE__ macro as it can get about the file location (i.e., full path). It's not really improper since I choosed GNU gcc, so everything is behaving as expected. What is not behaving as expected (on my point of view, with is relative), the improper assumption is that Cmake doesn't hide the path to the project Since the problem is thus firmly located on the source code side (i.e. its assumptions about __FILE__), I'd suggest treating the problem right there, using e.g. the discussion's strrchr() solution (workaround?) to achieve a slightly improved guarantee of gaining sufficiently constant output format (but note that Keith Thompson noted that the C language itself does not have any business dealing with path separator definitions). Thanks for pointing this link, very interesting. The strrchr() solution is demanding computation at run time, which is quite a pity (not to see a problem as it is an embedded project). But at least it's a solution. I tried to use the suggested trigger set_source_files_properties to define my own __FILE__ but it doesn't works with included files (it shows main.cpp instead oh dummy.hpp) http://www.cmake.org/pipermail/cmake/2011-December/048281.html So this way is a dead end because the compilator (and the one that creates its command line) is the only one to be aware of this information. Beside that, as I would really like to simplify the VERBOSE=2 make output to be able to debug what CMake generates I currently have plenty of path with 20 or more folder level including many ../.., I am looking on making CMake giving relatives paths to gcc. I guess the problem is that CMake is operating from a separate binary tree as its base, thus it obviously needs to pass full paths to the source files to the compiler, to get to the other source dir over there. The alternative would be to
Re: [CMake] Problems with ctest output using clang compiler on Mac
Hi,
We have the same problem here with ctest and clang on Mac OS X.
Versions used are :
- clang 4.2, from XCode 4.6DP4 on Mac OS X 10.7
- cmake 2.8.10.2
In our ctest script, compilation is launched with 4 jobs (make -j4).
In our dashboard (and same thing when directly looking at the text output of
the ctest process), we notice that some compilations outputs get mixed.
In this case we can see the beginning of one compilation process output
starting in the middle of a previous compilation output.
This leads to some mixed outputs of two different compilation processes, that
cannot be properly interpreted by ctest as warning, and are therefore displayed
as errors.
At the end of this mail, an example of the kind of mixes we have.
Is anybody facing the same problem and is there a workaround available ?
Kind regards
Ananda
-
12:
In file included from
O/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/functional/hash/hash.hppIn
file included from
/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/date_time/gregorian/gregorian.hppO:S15:
T:_I34/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/functional/hash/detail/hash_float.hpp:T71E:R:
25In file included from AT:O Rwarning:
_/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/date_time/gregorian/parsers.hppFcAa:s13tC
:
In file included from
AD/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/date_time/date_parsing.hpp:fEr_oP15:
mL US'In file included from 'c
har/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/tokenizer.hpp:20
*:
In file included from '
/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/token_iterator.hpp:24t
return tmp += n; \o ':
s
^t/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/token_functions.hpp
:312:d:33: :swarning:
uiznuse_e/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/gil/image_view.hpp:d125
t: p68a:* 'note: ir(n aiansmetaktae n'tuianrt iso'n igonefd lofnugb' * [')n-
Wicutninocnr etaesmpeulass rteed-peaq rsameupiteercri]al
eidz aatliiognn m'ebnoto sftr:o:mo p1e rtaot o8static void assign(Iterator b,
Iterator e, Token t) { }
^
r
[+-Wbcoa/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/token_functions.hpposstt:-:a312l:i:gg45inl]
[ 58%] Building CXX object
libProcessing/tests/CMakeFiles/jitterestimationfilter_test.dir/jitterestimationfilter_test.cpp.o
:::iterator warning: _frunom_2dusbedoos parat:me:gteilr ::'eme'
mo[r-Wuy_basnued_se2d_lod-capatorbrametooerst]
::gil:seed = *(std::size_t*) ptr;
:m^~
emory_bstatic void assign(Iterator b, Iterator e, Token t) { }
^
ased/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/token_functions.hpp:312_st:55ep:
_iwarning: utenurasetod rconparstamete ur ns'tig' [-Wneund usshedor-parat
met/usr/local/mkt-dev/install/boost-1.52.0_patch_range_search_n-macosx10.7-x86_64-gnu++11_libc++-20121226/build-x86_64/include/boost/functional/hash/detail/hash_float.hpp*:er76
:]
Andreas Fetzer strom...@gmx.de wrote
Hi there,
On our dashboard some warnings are treated as errors and hence the build fails
(only for Mac OS X systems):
http://cdash.mitk.org/viewBuildError.php?buildid=132336
http://cdash.mitk.org/viewBuildError.php?buildid=132336
Apparently not the hole output line of the clang compiler was considered. This
happens especially when we are using the apple clang compiler.
Is this a issue of ctest?
Regards
Andreas
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro!https://freundschaftswerbung.gmx.de
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to set the cmake variable on windows
Hello, When I try to execute cmake on the terminal on windows, I get an error. (See attachment). It seems that some variables arent set. Are there environmental variables or variables set in a specific file. Thanks a lot your support Happy new year. Best regards mparchet CMake Warning at CMakeLists.txt:1 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Warning at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/Platform/Windows-cl.cmake:28 (ENABLE_LANGUAGE): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. Call Stack (most recent call first): c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeCInformation.cmake:60 (INCLUDE) CMakeLists.txt:1 (project) CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. -- Check for CL compiler version -- Check for CL compiler version - failed -- Check if this is a free VC compiler -- Check if this is a free VC compiler - yes -- Using FREE VC TOOLS, NO DEBUG available -- Check for working C compiler: cl CMake Warning at CMakeLists.txt:2 (PROJECT): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. CMake Warning at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/Platform/Windows-cl.cmake:28 (ENABLE_LANGUAGE): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. Call Stack (most recent call first): c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeCInformation.cmake:60 (INCLUDE) CMakeLists.txt:2 (PROJECT) CMake Error at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/Platform/Windows-cl.cmake:28 (ENABLE_LANGUAGE) c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeCInformation.cmake:60 (INCLUDE) CMakeLists.txt:2 (PROJECT) CMake Error: CMAKE_RC_COMPILER not set, after EnableLanguage CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: cl -- broken CMake Error at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler cl is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: your CXX compiler: cl was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name. -- Configuring incomplete, errors occurred! -- 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] TR: How to set the cmake variable on windows
My compilretr is minGW. De : Parchet Michaël [mailto:mparc...@sunrise.ch] Envoyé : jeudi 10 janvier 2013 21:36 À : cmake@cmake.org; 'KDE on Windows' Objet : How to set the cmake variable on windows Hello, When I try to execute cmake on the terminal on windows, I get an error. (See attachment). It seems that some variables arent set. Are there environmental variables or variables set in a specific file. Thanks a lot your support Happy new year. Best regards mparchet CMake Warning at CMakeLists.txt:1 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Warning at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/Platform/Windows-cl.cmake:28 (ENABLE_LANGUAGE): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. Call Stack (most recent call first): c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeCInformation.cmake:60 (INCLUDE) CMakeLists.txt:1 (project) CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. -- Check for CL compiler version -- Check for CL compiler version - failed -- Check if this is a free VC compiler -- Check if this is a free VC compiler - yes -- Using FREE VC TOOLS, NO DEBUG available -- Check for working C compiler: cl CMake Warning at CMakeLists.txt:2 (PROJECT): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. CMake Warning at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/Platform/Windows-cl.cmake:28 (ENABLE_LANGUAGE): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. Call Stack (most recent call first): c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeCInformation.cmake:60 (INCLUDE) CMakeLists.txt:2 (PROJECT) CMake Error at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/Platform/Windows-cl.cmake:28 (ENABLE_LANGUAGE) c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeCInformation.cmake:60 (INCLUDE) CMakeLists.txt:2 (PROJECT) CMake Error: CMAKE_RC_COMPILER not set, after EnableLanguage CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: cl -- broken CMake Error at c:/kdeRoot/dev-utils/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler cl is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) CMake Error: your C compiler: cl was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name. CMake Error: your CXX compiler: cl was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name. -- Configuring incomplete, errors occurred! -- 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] Blog on parallel builds with CMake
I just put up a blog about parallel builds with CMake, that might be of interest to folks on the list: http://www.kitware.com/blog/home/post/434 -Bill -- 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] Blog on parallel builds with CMake
Good read. The only suggestion I would make is for Unix Makefiles, rather than running 'make -jN' is to run 'make -j -lN' which tells make to use as many cores until the load is greater than N. This is nice because if I have a 12 core system, I can do 'make -j -l12' and it will build using 12 if I'm not doing anything else. But if I'm, say, looking at data in Paraview and that's using up a core, then make will only take 11 cores and not bog my system down. It makes it much nicer if you are doing multiple things on the same machine doing the compilation. Tim - Original Message - From: Bill Hoffman bill.hoff...@kitware.com To: cmake cmake@cmake.org Sent: Thursday, January 10, 2013 4:28:46 PM Subject: [CMake] Blog on parallel builds with CMake I just put up a blog about parallel builds with CMake, that might be of interest to folks on the list: http://www.kitware.com/blog/home/post/434 -Bill -- 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] How to set the cmake variable on windows
Hello, How can I set minGW as default cmake compiler on windows ? Tanks for your answer. Regards mparchet Le 10 janv. 2013 à 22:47, Patrick von Reth patrick.vonr...@gmail.com a écrit : Hi you have to use cmake -GMinGW Makefiles ... On 10/01/2013, Parchet Michaël mparc...@sunrise.ch wrote: My compilretr is minGW. De : Parchet Michaël [mailto:mparc...@sunrise.ch] Envoyé : jeudi 10 janvier 2013 21:36 À : cmake@cmake.org; 'KDE on Windows' Objet : How to set the cmake variable on windows Hello, When I try to execute cmake on the terminal on windows, I get an error. (See attachment). It seems that some variables aren’t set. Are there environmental variables or variables set in a specific file. Thanks a lot your support Happy new year. Best regards mparchet ___ Kde-windows mailing list kde-wind...@kde.org https://mail.kde.org/mailman/listinfo/kde-windows -- 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] SWIG and dependency scanning
I am using SWIG with #include directives in the interface file. When I compile the project for the first time everything works fine, but when I make modifications to the header file included by the interface file the generated cxx wrapper file is not re-generated. But the generated cxx wrapper file is re-compiled, it has the same #include directive as the interface file, but it hasn't changed. So my question is how can I get the interface file to have a dependency on the #include'd header file? Thanks, Hugh. -- 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] CMake 2.8.10 with Xcode 4.4.1
Hello, I just had this happening with CMake 2.8.10 ( from a recent macports ) and with XCode 4.5.2. I built the step1 tutorial in its source dir : bash-3.2$ cmake -G XCode .^M -- The C compiler identification is Clang 4.1.0^M -- The CXX compiler identification is Clang 4.1.0^M -- Check for working C compiler using: Xcode^M -- Check for working C compiler using: Xcode -- works^M -- Detecting C compiler ABI info^M -- Detecting C compiler ABI info - done^M -- Check for working CXX compiler using: Xcode^M -- Check for working CXX compiler using: Xcode -- works^M -- Detecting CXX compiler ABI info^M -- Detecting CXX compiler ABI info - done^M -- Configuring done^M -- Generating done^M -- Build files have been written to: /Users/alexandre.vincent/Projects/cmake-2.8.10.2/Tests/Tutorial/Step1^M bash-3.2$ xcodebuild Tuto^Grial.xcodeproj/^M === BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Tutorial WITH THE DEFAULT CONFIGURATION (Debug) ===^M Check dependencies^M unsupported build action 'Tutorial.xcodeproj'^M ^M ^M ** BUILD FAILED **^M ^M ^M The following build commands failed:^M Check dependencies^M (1 failure)^M bash-3.2$ exit^M Script done on Fri Jan 11 16:09:08 2013 Let me know if you need any more information. Cheers, -- AlexV 2012/11/29 David Cole david.c...@kitware.com I can't for the life of me reproduce this. I've tried on my own Mac with Xcode 4.2, and on a colleague's Mac with Xcode 4.5.2. I can't seem to find a 4.4.1 machine to try this out on... Is this a problem for anybody else using CMake 2.8.10 on a Mac with the Xcode generator? Can you send the full output of the configure step (in a clean build directory)? Also, the output of running find CMakeFiles after the configure is done? (What files exist in CMakeFiles after a fresh configure...?) The file that's missing should be generated during the first configure. cd /Users/nicholas/temp/xcode find CMakeFiles Very mysterious. On Thu, Nov 22, 2012 at 1:08 AM, Nicholas Yue yue.nicho...@gmail.comwrote: On 19/11/12 10:31 PM, David Cole wrote: In the CMake source tree, can you try to build Tests/Tutorial/Step1 with the Xcode generator and report the results? $ xcodebuild Tutorial.xcodeproj === BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Tutorial WITH THE DEFAULT CONFIGURATION (Debug) === Check dependencies unsupported build action 'Tutorial.xcodeproj' ** BUILD FAILED ** The following build commands failed: Check dependencies (1 failure) Can you send your simple CMakeLists.txt file and its single source here? Files are attached What does your machine report when you run xcode-select -print-path? $ xcode-select -print-path /Applications/Xcode.app/**Contents/Developer Cheers -- Nicholas Yue Graphics - RenderMan, Visualization, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/**nicholasyuehttp://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/**naiadtoolshttps://vimeo.com/channels/naiadtools -- 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
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1516-gd890530
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 d890530f055f6ff8a407f86d80ff302c1c93263d (commit)
via c8ee07d0adade6b838c0ee8e7c2549285a3b6b85 (commit)
from fba9a5a6a2243583fa9477bd61177c226eea1fdd (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=d890530f055f6ff8a407f86d80ff302c1c93263d
commit d890530f055f6ff8a407f86d80ff302c1c93263d
Merge: fba9a5a c8ee07d
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 10 09:45:44 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 10 09:45:44 2013 -0500
Merge topic 'qt4-target-depends' into next
c8ee07d FindQt4: Add INTERFACE includes and defines to Qt4 targets
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8ee07d0adade6b838c0ee8e7c2549285a3b6b85
commit c8ee07d0adade6b838c0ee8e7c2549285a3b6b85
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 31 00:55:38 2012 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Jan 10 09:44:50 2013 -0500
FindQt4: Add INTERFACE includes and defines to Qt4 targets
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 381141c..a9e9d82 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -418,6 +418,15 @@ macro (_QT4_ADJUST_LIB_VARS _camelCaseBasename)
set_property(TARGET Qt4::${_camelCaseBasename}PROPERTY
IMPORTED_LOCATION_DEBUG ${QT_${basename}_LIBRARY_DEBUG} )
endif()
endif ()
+ set_property(TARGET Qt4::${_camelCaseBasename} PROPERTY
+INTERFACE_INCLUDE_DIRECTORIES
+ ${QT_${basename}_INCLUDE_DIR}
+ )
+ string(REGEX REPLACE ^QT _stemname ${basename})
+ set_property(TARGET Qt4::${_camelCaseBasename} PROPERTY
+INTERFACE_COMPILE_DEFINITIONS
+ QT_${_stemname}_LIB
+ )
endif()
# If QT_USE_IMPORTED_TARGETS is enabled, the QT_QTFOO_LIBRARY variables
are set to point at these
@@ -952,6 +961,14 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
${_PROPERTY}
Qt4::Qt${_DEPEND}
)
+set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES
+
$TARGET_PROPERTY:Qt4::Qt${_DEPEND},INTERFACE_INCLUDE_DIRECTORIES
+)
+set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
+ INTERFACE_COMPILE_DEFINITIONS
+
$TARGET_PROPERTY:Qt4::Qt${_DEPEND},INTERFACE_COMPILE_DEFINITIONS
+)
endforeach()
endif()
endmacro()
@@ -968,6 +985,11 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
# Set QT_xyz_LIBRARY variable and add
# library include path to QT_INCLUDES
_QT4_ADJUST_LIB_VARS(QtCore)
+ set_property(TARGET Qt4::QtCore APPEND PROPERTY
+INTERFACE_INCLUDE_DIRECTORIES
+ ${QT_MKSPECS_DIR}/default
+ ${QT_INCLUDE_DIR}
+ )
foreach(QT_MODULE ${QT_MODULES})
_QT4_ADJUST_LIB_VARS(${QT_MODULE})
@@ -992,6 +1014,10 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
# headers.
# Everything depends on QtCore, but that is covered above already
_qt4_add_target_depends(Qt3Support Sql Gui Network)
+ if (TARGET Qt4::Qt3Support)
+# An additional define is required for QT3_SUPPORT
+set_property(TARGET Qt4::Qt3Support APPEND PROPERTY
INTERFACE_COMPILE_DEFINITIONS QT3_SUPPORT)
+ endif()
_qt4_add_target_depends(QtDeclarative Script Gui)
_qt4_add_target_depends(QtDesigner Gui)
_qt4_add_target_depends(QtHelp Gui)
diff --git a/Tests/Qt4Targets/CMakeLists.txt b/Tests/Qt4Targets/CMakeLists.txt
index 3adff48..9bd7a64 100644
--- a/Tests/Qt4Targets/CMakeLists.txt
+++ b/Tests/Qt4Targets/CMakeLists.txt
@@ -4,11 +4,18 @@ project(Qt4Targets)
find_package(Qt4 REQUIRED)
-include_directories(${QT_INCLUDES})
-
add_executable(Qt4Targets WIN32 main.cpp)
target_link_libraries(Qt4Targets Qt4::QtGui)
if (WIN32)
target_link_libraries(Qt4Targets Qt4::qtmain)
endif()
+
+set_property(TARGET Qt4Targets APPEND PROPERTY
+ INCLUDE_DIRECTORIES
+$TARGET_PROPERTY:Qt4::QtGui,INTERFACE_INCLUDE_DIRECTORIES
+)
+set_property(TARGET Qt4Targets APPEND PROPERTY
+ COMPILE_DEFINITIONS
+$TARGET_PROPERTY:Qt4::QtGui,INTERFACE_COMPILE_DEFINITIONS
+)
diff --git a/Tests/Qt4Targets/main.cpp b/Tests/Qt4Targets/main.cpp
index f4890fa..3c98c99 100644
--- a/Tests/Qt4Targets/main.cpp
+++ b/Tests/Qt4Targets/main.cpp
@@ -4,6 +4,14 @@
#include QString
+#ifndef QT_CORE_LIB
+#error Expected QT_CORE_LIB
+#endif
+
+#ifndef QT_GUI_LIB
+#error Expected QT_GUI_LIB
+#endif
+
int main(int argc, char **argv)
{
QApplication app(argc, argv);
---
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1519-g6d87665
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 6d87665bdd2e759b41baf140b4417fe7dfd2237c (commit)
via fc61a7a746c3c899d42ccff3014686365c36ee11 (commit)
via 8a37ebec784cefe4f04cb8897c23a014c3930052 (commit)
from d890530f055f6ff8a407f86d80ff302c1c93263d (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=6d87665bdd2e759b41baf140b4417fe7dfd2237c
commit 6d87665bdd2e759b41baf140b4417fe7dfd2237c
Merge: d890530 fc61a7a
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 10 09:49:55 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 10 09:49:55 2013 -0500
Merge topic 'target-includes-defines-commands' into next
fc61a7a Add the target_compile_definitions command.
8a37ebe Add the target_include_directories command.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc61a7a746c3c899d42ccff3014686365c36ee11
commit fc61a7a746c3c899d42ccff3014686365c36ee11
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Jan 8 00:34:41 2013 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Jan 10 09:46:58 2013 -0500
Add the target_compile_definitions command.
This is a convenience API to populate the corresponding properties.
diff --git a/Source/cmCommands.cxx b/Source/cmCommands.cxx
index 6b315ea..227b226 100644
--- a/Source/cmCommands.cxx
+++ b/Source/cmCommands.cxx
@@ -28,6 +28,7 @@
#include cmRemoveDefinitionsCommand.cxx
#include cmSourceGroupCommand.cxx
#include cmSubdirDependsCommand.cxx
+#include cmTargetCompileDefinitionsCommand.cxx
#include cmTargetIncludeDirectoriesCommand.cxx
#include cmTargetPropCommandBase.cxx
#include cmUseMangledMesaCommand.cxx
@@ -69,6 +70,7 @@ void GetPredefinedCommands(std::listcmCommand*
commands.push_back(new cmSourceGroupCommand);
commands.push_back(new cmSubdirDependsCommand);
commands.push_back(new cmTargetIncludeDirectoriesCommand);
+ commands.push_back(new cmTargetCompileDefinitionsCommand);
commands.push_back(new cmUseMangledMesaCommand);
commands.push_back(new cmUtilitySourceCommand);
commands.push_back(new cmVariableRequiresCommand);
diff --git a/Source/cmTargetCompileDefinitionsCommand.cxx
b/Source/cmTargetCompileDefinitionsCommand.cxx
new file mode 100644
index 000..492a1b7
--- /dev/null
+++ b/Source/cmTargetCompileDefinitionsCommand.cxx
@@ -0,0 +1,57 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2013 Stephen Kelly steve...@gmail.com
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+#include cmTargetCompileDefinitionsCommand.h
+
+#include cmMakefileIncludeDirectoriesEntry.h
+
+bool cmTargetCompileDefinitionsCommand
+::InitialPass(std::vectorstd::string const args, cmExecutionStatus )
+{
+ return this-HandleArguments(args, COMPILE_DEFINITIONS);
+}
+
+void cmTargetCompileDefinitionsCommand
+::HandleImportedTargetInvalidScope(const std::string scope,
+ const std::string tgt)
+{
+ cmOStringStream e;
+ e Cannot specify scope compile definitions for imported
+ target \ tgt \. Compile definitions can only be
+ specified for an imported target in the INTERFACE mode.;
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
+}
+
+void cmTargetCompileDefinitionsCommand
+::HandleMissingTarget(const std::string name)
+{
+ cmOStringStream e;
+ e Cannot specify compile definitions for target \ name \
+ which is not built by this project.;
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
+}
+
+bool cmTargetCompileDefinitionsCommand
+::HandleNonTargetArg(std::string content,
+ const std::string sep,
+ const std::string entry,
+ const std::string )
+{
+ content += sep + entry;
+ return true;
+}
+
+void cmTargetCompileDefinitionsCommand
+::HandleDirectContent(cmTarget *tgt, const std::string content,
+ bool)
+{
+ tgt-AppendProperty(COMPILE_DEFINITIONS, content.c_str());
+}
diff --git a/Source/cmTargetCompileDefinitionsCommand.h
b/Source/cmTargetCompileDefinitionsCommand.h
new file mode 100644
index 000..707610e
--- /dev/null
+++
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1521-gd1e5720
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 d1e5720991480016ae2ff0aaff14e2653199fbd7 (commit)
via 3581b96caa1d7bd6c02e85baf72ce28b5128e5e7 (commit)
from 6d87665bdd2e759b41baf140b4417fe7dfd2237c (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=d1e5720991480016ae2ff0aaff14e2653199fbd7
commit d1e5720991480016ae2ff0aaff14e2653199fbd7
Merge: 6d87665 3581b96
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 10 09:56:16 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 10 09:56:16 2013 -0500
Merge topic 'INTERFACE_POSITION_INDEPENDENT_CODE' into next
3581b96 Process the INTERFACE_PIC property from linked dependencies
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3581b96caa1d7bd6c02e85baf72ce28b5128e5e7
commit 3581b96caa1d7bd6c02e85baf72ce28b5128e5e7
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Nov 5 12:46:26 2012 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Jan 10 09:54:52 2013 -0500
Process the INTERFACE_PIC property from linked dependencies
This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Add a test covering the consistency checks on platforms where they run.
diff --git a/Source/cmGlobalXCodeGenerator.cxx
b/Source/cmGlobalXCodeGenerator.cxx
index 4c26b82..2cfe4da 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -1639,14 +1639,16 @@ void
cmGlobalXCodeGenerator::CreateBuildSettings(cmTarget target,
if(strcmp(lang, CXX) == 0)
{
this-CurrentLocalGenerator-AddLanguageFlags(cflags, C, configName);
- this-CurrentLocalGenerator-AddCMP0018Flags(cflags, target, C);
+ this-CurrentLocalGenerator-AddCMP0018Flags(cflags, target,
+ C, configName);
}
// Add language-specific flags.
this-CurrentLocalGenerator-AddLanguageFlags(flags, lang, configName);
// Add shared-library flags if needed.
-this-CurrentLocalGenerator-AddCMP0018Flags(flags, target, lang);
+this-CurrentLocalGenerator-AddCMP0018Flags(flags, target,
+ lang, configName);
}
else if(binary)
{
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index b557ca1..ecf6b41 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1984,7 +1984,8 @@ void cmLocalGenerator::AddSharedFlags(std::string flags,
//
void cmLocalGenerator::AddCMP0018Flags(std::string flags, cmTarget* target,
- std::string const lang)
+ std::string const lang,
+ const char *config)
{
int targetType = target-GetType();
@@ -1997,8 +1998,18 @@ void cmLocalGenerator::AddCMP0018Flags(std::string
flags, cmTarget* target,
}
else
{
-// Add position independendent flags, if needed.
-if (target-GetPropertyAsBool(POSITION_INDEPENDENT_CODE))
+if (target-GetType() == cmTarget::OBJECT_LIBRARY)
+{
+ if (target-GetPropertyAsBool(POSITION_INDEPENDENT_CODE))
+{
+this-AddPositionIndependentFlags(flags, lang, targetType);
+}
+ return;
+}
+
+if (target-GetLinkInterfaceDependentBoolProperty(
+POSITION_INDEPENDENT_CODE,
+config))
{
this-AddPositionIndependentFlags(flags, lang, targetType);
}
diff --git a/Source/cmLocalGenerator.h b/Source/cmLocalGenerator.h
index 63559d7..b2ff0c4 100644
--- a/Source/cmLocalGenerator.h
+++ b/Source/cmLocalGenerator.h
@@ -142,7 +142,7 @@ public:
void AddLanguageFlags(std::string flags, const char* lang,
const char* config);
void AddCMP0018Flags(std::string flags, cmTarget* target,
- std::string const lang);
+ std::string const lang, const char *config);
void AddConfigVariableFlags(std::string flags, const char* var,
const char* config);
///! Append flags to a string.
diff --git a/Source/cmMakefileTargetGenerator.cxx
b/Source/cmMakefileTargetGenerator.cxx
index 9bf6b7d..64fcfce 100644
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-414-g8a7a4c0
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 8a7a4c043c2fede043ce8bf8676a95e1b779fe5e (commit) via 32fb667a0c9622999d7054e809863a8e70010059 (commit) via 9fdfe07411d8846f2adf0e46cf9046238c149d2b (commit) from 96c1a1b787155f98265bcac2338b25ad579faca0 (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=8a7a4c043c2fede043ce8bf8676a95e1b779fe5e commit 8a7a4c043c2fede043ce8bf8676a95e1b779fe5e Merge: 96c1a1b 32fb667 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 10 10:22:09 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 10 10:22:09 2013 -0500 Merge topic 'update-KWIML' 32fb667 Merge branch 'upstream-kwiml' into update-KWIML 9fdfe07 KWIML: Teach ABI about 'long long' on older GNU --- Summary of changes: Utilities/KWIML/ABI.h.in |4 +++- 1 files changed, 3 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
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-421-g42d9df9
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 42d9df9f4f5b06de0f75859cc40750c9b8eec9a1 (commit) via 0380f36cd8dbdf7a89f8fac91d99235e75075bde (commit) via 8e9630c719f59f69f813e3eb4a4f91ba2396b4ef (commit) via 50bfedf391a078e628bf1259f819da42dea1cde0 (commit) via 3d2e6a06874603ebe6152045c34de9147a0c11dc (commit) via 7a1b961de8b79416d168355e71f5af80fa4dbd02 (commit) via ed96d9a605471694465dd7142dd25748dfdf3a90 (commit) from 8a7a4c043c2fede043ce8bf8676a95e1b779fe5e (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=42d9df9f4f5b06de0f75859cc40750c9b8eec9a1 commit 42d9df9f4f5b06de0f75859cc40750c9b8eec9a1 Merge: 8a7a4c0 0380f36 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 10 10:22:14 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 10 10:22:14 2013 -0500 Merge topic 'Haiku' 0380f36 FindOpenGL: add Haiku paths 8e9630c FindGLUT: BeOS does not have libXi and libXmu 50bfedf FindLua51: do not try to link libm on BeOS 3d2e6a0 check for Haiku only with __HAIKU__ 7a1b961 Haiku no longer defines __BEOS__ ed96d9a bootstrap: use better defaults for Haiku --- Summary of changes: Modules/CMakeFortranCompilerId.F.in |6 +- Modules/CMakePlatformId.h.in |5 + Modules/CheckForPthreads.c |2 +- Modules/FindGLUT.cmake | 28 +--- Modules/FindLua51.cmake |2 +- Modules/FindOpenGL.cmake | 30 +- Source/CPack/cmCPackGeneratorFactory.cxx |4 ++-- Source/cmCTest.cxx |2 +- bootstrap|4 +++- 9 files changed, 52 insertions(+), 31 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-427-gfeb9ffb
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 feb9ffb6815b4367634a1543f42f50ae2f3c4c98 (commit) via c8ee07d0adade6b838c0ee8e7c2549285a3b6b85 (commit) from 281f3d9579ac3b2559e8e2028cbcfd33d83e8dac (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=feb9ffb6815b4367634a1543f42f50ae2f3c4c98 commit feb9ffb6815b4367634a1543f42f50ae2f3c4c98 Merge: 281f3d9 c8ee07d Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 10 10:22:40 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 10 10:22:40 2013 -0500 Merge topic 'qt4-target-depends' c8ee07d FindQt4: Add INTERFACE includes and defines to Qt4 targets --- Summary of changes: Modules/FindQt4.cmake | 26 ++ Tests/Qt4Targets/CMakeLists.txt | 11 +-- Tests/Qt4Targets/main.cpp |8 3 files changed, 43 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-430-g325e92f
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 325e92fa22cb20a3d4bccbf1f663c28b34f8b04c (commit) via fc61a7a746c3c899d42ccff3014686365c36ee11 (commit) via 8a37ebec784cefe4f04cb8897c23a014c3930052 (commit) from feb9ffb6815b4367634a1543f42f50ae2f3c4c98 (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=325e92fa22cb20a3d4bccbf1f663c28b34f8b04c commit 325e92fa22cb20a3d4bccbf1f663c28b34f8b04c Merge: feb9ffb fc61a7a Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 10 10:22:46 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 10 10:22:46 2013 -0500 Merge topic 'target-includes-defines-commands' fc61a7a Add the target_compile_definitions command. 8a37ebe Add the target_include_directories command. --- Summary of changes: Source/cmCommands.cxx |5 + Source/cmTargetCompileDefinitionsCommand.cxx | 57 Source/cmTargetCompileDefinitionsCommand.h | 91 Source/cmTargetIncludeDirectoriesCommand.cxx | 74 ++ Source/cmTargetIncludeDirectoriesCommand.h | 95 + Source/cmTargetPropCommandBase.cxx | 144 Source/cmTargetPropCommandBase.h | 57 .../target_compile_definitions/CMakeLists.txt | 26 .../target_compile_definitions/consumer.cpp| 18 +++ .../target_compile_definitions/main.cpp| 14 ++ .../target_include_directories/CMakeLists.txt | 50 +++ .../target_include_directories/consumer.cpp| 27 .../target_include_directories/main.cpp| 22 +++ Tests/CMakeLists.txt |2 + 14 files changed, 682 insertions(+), 0 deletions(-) create mode 100644 Source/cmTargetCompileDefinitionsCommand.cxx create mode 100644 Source/cmTargetCompileDefinitionsCommand.h create mode 100644 Source/cmTargetIncludeDirectoriesCommand.cxx create mode 100644 Source/cmTargetIncludeDirectoriesCommand.h create mode 100644 Source/cmTargetPropCommandBase.cxx create mode 100644 Source/cmTargetPropCommandBase.h create mode 100644 Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt create mode 100644 Tests/CMakeCommands/target_compile_definitions/consumer.cpp create mode 100644 Tests/CMakeCommands/target_compile_definitions/main.cpp create mode 100644 Tests/CMakeCommands/target_include_directories/CMakeLists.txt create mode 100644 Tests/CMakeCommands/target_include_directories/consumer.cpp create mode 100644 Tests/CMakeCommands/target_include_directories/main.cpp 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.10.2-1533-g66f05a4
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 66f05a4a4b061058ecd41bff01950b168b997e3a (commit)
via 93034a8350102e308fa5bca8d89bf3f6fae12771 (commit)
from 809f8312515e9dd7aef4c93d87d243532b255dbd (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=66f05a4a4b061058ecd41bff01950b168b997e3a
commit 66f05a4a4b061058ecd41bff01950b168b997e3a
Merge: 809f831 93034a8
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 10 12:04:54 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 10 12:04:54 2013 -0500
Merge topic 'fix-imported-lib-linking-test' into next
93034a8 Fix linking to imported libraries test.
diff --cc Tests/ExportImport/Import/A/deps_iface.c
index c0d9735,e73ca26..91c42fe
--- a/Tests/ExportImport/Import/A/deps_iface.c
+++ b/Tests/ExportImport/Import/A/deps_iface.c
@@@ -20,9 -18,7 +20,9 @@@
extern int testLibDepends(void);
- int main(int,char **)
+ int main()
{
- return testLibDepends();
+ TestLibLibraryRequired ifaceDep;
+
+ return testLibDepends() + ifaceDep.foo();
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93034a8350102e308fa5bca8d89bf3f6fae12771
commit 93034a8350102e308fa5bca8d89bf3f6fae12771
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 10 17:11:12 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Jan 10 17:13:19 2013 +0100
Fix linking to imported libraries test.
Make a C executable instead of attempting to make a C++ static
library (and not really succeeding). This was introduced in
commit 894f52f3 (Handle INTERFACE properties transitively for
includes and defines., 2012-09-23).
diff --git a/Tests/ExportImport/Import/A/CMakeLists.txt
b/Tests/ExportImport/Import/A/CMakeLists.txt
index b77562e..56cfea0 100644
--- a/Tests/ExportImport/Import/A/CMakeLists.txt
+++ b/Tests/ExportImport/Import/A/CMakeLists.txt
@@ -157,8 +157,8 @@ endif()
# Test that dependent imported targets have usable
# INTERFACE_COMPILE_DEFINITIONS and INTERFACE_INCLUDE_DIRECTORIES
-add_library(deps_iface deps_iface.cpp)
-target_link_libraries(deps_iface testLibsDepends)
+add_executable(deps_iface deps_iface.c)
+target_link_libraries(deps_iface testLibDepends)
set_property(TARGET deps_iface APPEND PROPERTY
COMPILE_DEFINITIONS
$TARGET_PROPERTY:testLibDepends,INTERFACE_COMPILE_DEFINITIONS
diff --git a/Tests/ExportImport/Import/A/deps_iface.cpp
b/Tests/ExportImport/Import/A/deps_iface.c
similarity index 94%
rename from Tests/ExportImport/Import/A/deps_iface.cpp
rename to Tests/ExportImport/Import/A/deps_iface.c
index 7190b92..e73ca26 100644
--- a/Tests/ExportImport/Import/A/deps_iface.cpp
+++ b/Tests/ExportImport/Import/A/deps_iface.c
@@ -18,7 +18,7 @@
extern int testLibDepends(void);
-int main(int,char **)
+int main()
{
return testLibDepends();
}
---
Summary of changes:
Tests/ExportImport/Import/A/CMakeLists.txt |4 ++--
.../Import/A/{deps_iface.cpp = deps_iface.c} |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
rename Tests/ExportImport/Import/A/{deps_iface.cpp = deps_iface.c} (95%)
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.10.2-1536-g3741269
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 3741269ac53dfa42b5106a506504fae1d2887679 (commit)
via 7e9411eac0faaa0201bc2a607d8de7f436e12d6a (commit)
via 4d6b6633a8ce78f6810a16ced55fc4190a2b42b8 (commit)
from 66f05a4a4b061058ecd41bff01950b168b997e3a (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=3741269ac53dfa42b5106a506504fae1d2887679
commit 3741269ac53dfa42b5106a506504fae1d2887679
Merge: 66f05a4 7e9411e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 10 12:05:38 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 10 12:05:38 2013 -0500
Merge topic 'LINK_INTERFACE_LIBRARIES-genex' into next
7e9411e Add test using shared libraries and INTERFACE genex
4d6b663 Fix typo in genex test invokation.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e9411eac0faaa0201bc2a607d8de7f436e12d6a
commit 7e9411eac0faaa0201bc2a607d8de7f436e12d6a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 10 18:01:46 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Jan 10 18:02:42 2013 +0100
Add test using shared libraries and INTERFACE genex
diff --git a/Tests/ExportImport/Export/CMakeLists.txt
b/Tests/ExportImport/Export/CMakeLists.txt
index fb17791..3e8b912 100644
--- a/Tests/ExportImport/Export/CMakeLists.txt
+++ b/Tests/ExportImport/Export/CMakeLists.txt
@@ -170,9 +170,29 @@ set_property(TARGET testLibLibraryRequired APPEND PROPERTY
${CMAKE_CURRENT_SOURCE_DIR}
)
-set_property(TARGET testLibRequired APPEND PROPERTY
+add_library(testSharedLibRequired SHARED testSharedLibRequired.cpp)
+generate_export_header(testSharedLibRequired)
+set_property(TARGET testSharedLibRequired APPEND PROPERTY
+ INCLUDE_DIRECTORIES ${CMAKE_CURRENT_BINARY_DIR}
+)
+set_property(TARGET testSharedLibRequired APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_BINARY_DIR}
+${CMAKE_CURRENT_SOURCE_DIR}
+)
+
+add_library(testSharedLibDepends SHARED testSharedLibDepends.cpp)
+set_property(TARGET testSharedLibDepends APPEND PROPERTY
+ INCLUDE_DIRECTORIES ${CMAKE_CURRENT_BINARY_DIR}
+)
+generate_export_header(testSharedLibDepends)
+
+set_property(TARGET testSharedLibDepends APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES
+$TARGET_PROPERTY:testSharedLibRequired,INTERFACE_INCLUDE_DIRECTORIES
+)
+set_property(TARGET testSharedLibDepends APPEND PROPERTY
LINK_INTERFACE_LIBRARIES
-$1:testLibLibraryRequired
+$1:$TARGET_NAME:testSharedLibRequired
)
install(TARGETS testLibRequired
@@ -183,10 +203,11 @@ install(TARGETS testLibRequired
testLibIncludeRequired5
testLibIncludeRequired6
testLibLibraryRequired
+testSharedLibRequired
EXPORT RequiredExp DESTINATION lib )
install(EXPORT RequiredExp NAMESPACE Req:: FILE testLibRequiredConfig.cmake
DESTINATION lib/cmake/testLibRequired)
-install(TARGETS testLibDepends EXPORT DependsExp DESTINATION lib )
+install(TARGETS testLibDepends testSharedLibDepends EXPORT DependsExp
DESTINATION lib )
install(EXPORT DependsExp FILE testLibDependsConfig.cmake DESTINATION
lib/cmake/testLibDepends)
diff --git a/Tests/ExportImport/Export/testSharedLibDepends.cpp
b/Tests/ExportImport/Export/testSharedLibDepends.cpp
new file mode 100644
index 000..e279207
--- /dev/null
+++ b/Tests/ExportImport/Export/testSharedLibDepends.cpp
@@ -0,0 +1,8 @@
+
+#include testSharedLibDepends.h
+
+int TestSharedLibDepends::foo()
+{
+ TestSharedLibRequired req;
+ return req.foo();
+}
diff --git a/Tests/ExportImport/Export/testSharedLibDepends.h
b/Tests/ExportImport/Export/testSharedLibDepends.h
new file mode 100644
index 000..b93143a
--- /dev/null
+++ b/Tests/ExportImport/Export/testSharedLibDepends.h
@@ -0,0 +1,14 @@
+
+#ifndef TESTSHAREDLIBDEPENDS_H
+#define TESTSHAREDLIBDEPENDS_H
+
+#include testsharedlibdepends_export.h
+
+#include testSharedLibRequired.h
+
+struct TESTSHAREDLIBDEPENDS_EXPORT TestSharedLibDepends
+{
+ int foo();
+};
+
+#endif
diff --git a/Tests/ExportImport/Export/testSharedLibRequired.cpp
b/Tests/ExportImport/Export/testSharedLibRequired.cpp
new file mode 100644
index 000..1ac34aa
--- /dev/null
+++ b/Tests/ExportImport/Export/testSharedLibRequired.cpp
@@ -0,0 +1,7 @@
+
+#include testSharedLibRequired.h
+
+int TestSharedLibRequired::foo()
+{
+ return 0;
+}
diff --git a/Tests/ExportImport/Export/testSharedLibRequired.h
b/Tests/ExportImport/Export/testSharedLibRequired.h
new file mode 100644
index 000..edaddd4
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1543-g5dcfc38
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 5dcfc38994547a5cee5d8c699a73c6aecb79877b (commit)
via 89e0a3a6802de97c096331196ae27b7fd4c35bea (commit)
via 94aeaf72c714eb184ec61bf6e7bc573bd1bc15c9 (commit)
via a3aedb8152ad6fcdb42fd04e45307eea6ce0043e (commit)
via b6036d104a95156e8524dbfeb5533d3a579d8837 (commit)
via cb1afbf466d126f233e93b2cdfa3f5c5dfe5b8f7 (commit)
via f99196dc0cde6e5868cc74c603a78b10f1ba324a (commit)
from 3741269ac53dfa42b5106a506504fae1d2887679 (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=5dcfc38994547a5cee5d8c699a73c6aecb79877b
commit 5dcfc38994547a5cee5d8c699a73c6aecb79877b
Merge: 3741269 89e0a3a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 10 12:07:53 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 10 12:07:53 2013 -0500
Merge topic 'LINK_INTERFACE_LIBRARIES-genex' into next
89e0a3a Allow generator expressions in LINK_INTERFACE_LIBRARIES.
94aeaf7 Split LINK_INTERFACE_LIBRARIES export handling into dedicated
method.
a3aedb8 Split the generator expression before extracting targets.
b6036d1 Extract the AddTargetNamespace method.
cb1afbf Don't pass a position when determining if a target name is a
literal.
f99196d Add cmGeneratorExpression::Split() API.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89e0a3a6802de97c096331196ae27b7fd4c35bea
commit 89e0a3a6802de97c096331196ae27b7fd4c35bea
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Jan 4 13:36:18 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Jan 10 18:06:57 2013 +0100
Allow generator expressions in LINK_INTERFACE_LIBRARIES.
The Config and IMPORTED_ variants may also contain generator
expressions.
If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.
1) In the case of non-static libraries, this is fine because the
user still has the option to populate the LINK_INTERFACE_LIBRARIES
with generator expressions if that is what is wanted.
2) In the case of static libraries, this prevents a footgun,
enforcing that the interface and the implementation are really
the same.
Otherwise, the LINK_LIBRARIES could contain a generator
expression which is evaluated with a different context at build
time, and when used as an imported target. That would mean that the
result of evaluating the INTERFACE_LINK_LIBRARIES property for
a static library would not necessarily be the 'link implementation'.
For example:
add_library(libone STATIC libone.cpp)
add_library(libtwo STATIC libtwo.cpp)
add_library(libthree STATIC libthree.cpp)
target_link_libraries(libtwo
$$STREQUAL:$TARGET_PROPERTY:TYPE,STATIC_LIBRARY:libone)
target_link_libraries(libthree libtwo)
If the LINK_LIBRARIES content was simply copied to the
IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
executables linking to libthree will not link to libone.
3) As the 'implementation is the interface' concept is to be
deprecated in the future anyway, this should be fine.
diff --git a/Source/cmExportFileGenerator.cxx b/Source/cmExportFileGenerator.cxx
index 5e5f455..94e24c7 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -359,9 +359,47 @@ cmExportFileGenerator
{
return;
}
- this-SetImportLinkProperty(suffix, target,
- IMPORTED_LINK_INTERFACE_LIBRARIES,
- iface-Libraries, properties, missingTargets);
+
+ if (iface-ImplementationIsInterface)
+{
+this-SetImportLinkProperty(suffix, target,
+IMPORTED_LINK_INTERFACE_LIBRARIES,
+iface-Libraries, properties, missingTargets);
+return;
+}
+
+ const char *propContent;
+
+ if (const char *prop_suffixed = target-GetProperty(
+(LINK_INTERFACE_LIBRARIES + suffix).c_str()))
+{
+propContent = prop_suffixed;
+}
+ else if (const char *prop = target-GetProperty(
+LINK_INTERFACE_LIBRARIES))
+{
+propContent = prop;
+}
+ else
+{
+return;
+}
+
+ if (!*propContent)
+{
+properties[IMPORTED_LINK_INTERFACE_LIBRARIES + suffix] = ;
+return;
+}
+
+ std::string
