[cmake-developers] [CMake 0014695]: CMake fails with XCode 4.6 and Qt 4 with CMAKE_OSX_DEPLOYMENT_TARGET
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14695 == Reported By:Juho Frits Assigned To: == Project:CMake Issue ID: 14695 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-01-14 04:40 EST Last Modified: 2014-01-14 04:40 EST == Summary:CMake fails with XCode 4.6 and Qt 4 with CMAKE_OSX_DEPLOYMENT_TARGET Description: CMake fails to set up CMAKE_OSX_SYSROOT when using XCode 4.6 with command line tools installed. I have only 10.7 and 10.8 SDKs installed. A minimal CMakeLists.txt to reproduce the issue is: PROJECT(test) SET(CMAKE_OSX_DEPLOYMENT_TARGET 10.5) FIND_PACKAGE(Qt4 COMPONENTS QtCore) CMake outputs the following errors: CMake Warning at /opt/local/cmake/Contents/share/cmake-2.8/Modules/Platform/Darwin.cmake:145 (message): CMAKE_OSX_DEPLOYMENT_TARGET is '10.5' but the matching SDK does not exist at: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.5.sdk Instead using SDK: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk matching the host OS X version. Call Stack (most recent call first): /opt/local/cmake/Contents/share/cmake-2.8/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:2 (PROJECT) CMake Error at /opt/local/cmake/Contents/share/cmake-2.8/Modules/Platform/Darwin.cmake:213 (message): CMAKE_OSX_DEPLOYMENT_TARGET is '10.5' but CMAKE_OSX_SYSROOT: is not set to a MacOSX SDK with a recognized version. Either set CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to empty. Call Stack (most recent call first): /opt/local/cmake/Contents/share/cmake-2.8/Modules/CMakeSystemSpecificInformation.cmake:36 (include) CMakeLists.txt:2 (PROJECT) CMake Error: Internal CMake error, TryCompile configure of cmake failed CMake 2.8.9 works fine. I haven't tested with CMake 2.8.10 or 2.8.11. == Issue History Date ModifiedUsername FieldChange == 2014-01-14 04:40 Juho Frits 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] [CMake 0014696]: CMake does not add QT_NO_DEBUG definition for RelWithDebInfo build type
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14696
==
Reported By:Gerry Boland
Assigned To:
==
Project:CMake
Issue ID: 14696
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-01-14 04:52 EST
Last Modified: 2014-01-14 04:52 EST
==
Summary:CMake does not add QT_NO_DEBUG definition for
RelWithDebInfo build type
Description:
In a Qt5 CMake project with code like the following:
cmake_minimum_required(VERSION 2.8.12)
find_package(Qt5Core REQUIRED)
target_link_libraries(${PROJECT_NAME} Qt5::Core)
Running with cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo I see that CMake does
not define QT_NO_DEBUG.
I interpreted the distinction between the Debug build type from the
RelWithDebInfo type as being that while RelWithDebInfo also does not strip
symbols from the generated binaries, it does allow developers to disable debug
helpers like run-time asserts or expensive printing statements. So for Qt,
setting QT_NO_DEBUG for RelWithDebInfo makes sense.
I'd like to know if my interpretation is correct before proceeding with a fix,
something like adding
set_property(TARGET ${_target} APPEND PROPERTY
COMPILE_DEFINITIONS_RELWITHDEBINFO QT_NO_DEBUG)
to Qt5CoreMacros.cmake around like 246.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-01-14 04:52 Gerry Boland 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] [CMake 0014697]: CMake does not add files to depend.make which are referenced by #include but not present on disk
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14697
==
Reported By:Christian Meyer
Assigned To:
==
Project:CMake
Issue ID: 14697
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2014-01-14 08:07 EST
Last Modified: 2014-01-14 08:07 EST
==
Summary:CMake does not add files to depend.make which are
referenced by #include but not present on disk
Description:
I added a bash script which should reproduce the problem on any system with a
working cmake installation when generating Makefiles.
It boils down to CMake omitting to add a #included file to the depend.make if
that include is not present on the hard drive at build time. Unfortunately it
does not fix this when that file is added afterwards.
Use Case:
1. User commits new source to a repository but omits a header file (fairly
common)
2. Build server initiates an incremental build which fails because the header
file is missing
3. User commits the missing header
4. Build server starts incremental build, build succeeds
5. User modifies the header
6. Expected: Build server rebuilds the source file which included the header;
Actual: Build server does nothing
Steps to Reproduce:
#!/bin/bash
# Test script to check for correct dependency updating in cmake when users
forget to commit header files to repositories
# Returns a non-zero exit code on test failure.
cmake --version
echo ### Create a minimal test project
echo #include \main.h\ main.cpp
echo int main() {return 0;} main.cpp
echo add_executable(TestApp main.cpp) CMakeLists.txt
echo ### Run CMake and build the project (should fail because main.h is
missing)
cmake .
make
echo ### At this point the build fails because the header is missing
echo # Create the header and make (now the build should pass)
touch main.h
make
echo ### Now the build passes normally
echo # Touch the header and make (now main.cpp should be rebuilt)
touch main.h
make
echo ### The build does not recompile main.cpp even though I touched main.h
echo # Display depend.make and observe that main.h is missing
cat CMakeFiles/TestApp.dir/depend.make
grep -q main.h CMakeFiles/TestApp.dir/depend.make
TEST_PASSED=$?
# Clean up for retest
make clean
rm main.h
exit ${TEST_PASSED}
Additional Information:
Script output on my local machine:
cmake version 2.8.7
### Create a minimal test project
### Run CMake and build the project (should fail because main.h is missing)
-- Configuring done
-- Generating done
-- Build files have been written to: /scratch/gridbox/cmake-test
[100%] Building CXX object CMakeFiles/TestApp.dir/main.cpp.o
/scratch/gridbox/cmake-test/main.cpp:1:18: fatal error: main.h: No such file or
directory
compilation terminated.
make[2]: *** [CMakeFiles/TestApp.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/TestApp.dir/all] Error 2
make: *** [all] Error 2
### At this point the build fails because the header is missing
# Create the header and make (now the build should pass)
[100%] Building CXX object CMakeFiles/TestApp.dir/main.cpp.o
Linking CXX executable TestApp
[100%] Built target TestApp
### Now the build passes normally
# Touch the header and make (now main.cpp should be rebuilt)
[100%] Built target TestApp
### The build does not recompile main.cpp even tough I touched main.h
# Display depend.make and observe that main.h is missing
# CMAKE generated file: DO NOT EDIT!
# Generated by Unix Makefiles Generator, CMake Version 2.8
CMakeFiles/TestApp.dir/main.cpp.o: main.cpp
==
Issue History
Date ModifiedUsername FieldChange
==
2014-01-14 08:07 Christian MeyerNew 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] RFC: add version to project() call
On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. -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] [CMake 0014698]: CMP0043 warning for COMPILE_DEFINITIONS without any suffix
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14698 == Reported By:Peter Kuemmel Assigned To: == Project:CMake Issue ID: 14698 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-01-14 17:27 CET Last Modified: 2014-01-14 17:27 CET == Summary:CMP0043 warning for COMPILE_DEFINITIONS without any suffix Description: CMake also warns about CMP0043 when only COMPILE_DEFINITIONS is used without any suffix. == Issue History Date ModifiedUsername FieldChange == 2014-01-14 17:27 Peter Kuemmel 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] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 13/01/14 16:51, Brad King wrote: On 01/13/2014 10:23 AM, Daniele E. Domenichelli wrote: Can I store CMAKE_INSTALL_PREFIX in an internal cached variable, check if it was changed since last run (i.e. CMAKE_INSTALL_PREFIX_OLD != CMAKE_INSTALL_PREFIX), check if the value is the default one, and eventually force-set it to the new default? Yes, that should work. Call it something internal-sounding like __LAST_CMAKE_INSTALL_PREFIX. Updated the topic to behave in this way. Can you please review it again? By the way, this is not the first time that I need to know if the value of a cached variable changed since the previous run, maybe it could be useful to have a standard way to do it... Cheers, Daniele -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
2014/1/14 Brad King brad.k...@kitware.com: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. What about CMAKE_PROJECT_VERSION_* for consistency with CMAKE_PROJECT_NAME? That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. -- 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] RFC: add version to project() call
On 2014-01-14 10:37, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides to start using project(...VERSION...). Now if B was using PROJECT_VERSION internally, it is broken. (Note that I'm implying that B is e.g. a separate repository that may not be as easy to update/fix as A.) That's an edge case though... not sure it's worth worrying about, but just saying... @Daniel, there is a CMAKE_PROJECT_NAME? I've always used just PROJECT_NAME... (Is PROJECT_NAME deprecated?) Anyway, while *hopefully* no one is setting e.g. CMAKE_PROJECT_VERSION there's still risk that they are. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net: On 2014-01-14 10:37, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides to start using project(...VERSION...). Now if B was using PROJECT_VERSION internally, it is broken. (Note that I'm implying that B is e.g. a separate repository that may not be as easy to update/fix as A.) That's an edge case though... not sure it's worth worrying about, but just saying... @Daniel, there is a CMAKE_PROJECT_NAME? I've always used just PROJECT_NAME... (Is PROJECT_NAME deprecated?) Anyway, while *hopefully* no one is setting e.g. CMAKE_PROJECT_VERSION there's still risk that they are. http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME The documentation for both variables is misleading. As far as I understand it, PROJECT_NAME is the name of the current project, while CMAKE_PROJECT_NAME us the name of the top-level project. This comes in handy when projects are added with 'add_subdirectory()'. If NOT CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME, the current project is not built independently. -- 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] RFC: add version to project() call
On 2014-01-14 14:11, Daniel Pfeifer wrote: 2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net: @Daniel, there is a CMAKE_PROJECT_NAME? http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME The documentation for both variables is misleading. As far as I understand it, PROJECT_NAME is the name of the current project, while CMAKE_PROJECT_NAME us the name of the top-level project. Ah, I see. I always use PROJECT_NAME as a way of not repeating the name of the target being built (this is in a project that generally has one library or executable per directory, and calls project() for each of them). In that case, I'd think CMAKE_PROJECT_VERSION would not be the correct thing to set (except maybe for the very first project() seen). Else I think we'd risk making this even more confusing ;-). -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Change default standard library implementation before used by compiler ?
Hi Folks, For both Slicer and SimpleITK, there is currently no support for the clang c++ standard library new implementation [1] that is now used by default on Maverick. It means that we currently expect our users to build the project by passing the flag: -DCMAKE_CXX_FLAGS_INIT:STRING=-stdlib=libstdc++ as explained in [2] To allow our users to build without explicitly passing flag, what would be recommended approach ? I was thinking about the following and would like to get your inputs / suggestions: 1) Add a compile test so that the flag could be updated before the first call to project()/enable_langage(). Is this possible ? 2) Wrap the project into a superbuild structure ... that could work but would be a ugly hack. Thanks for your help, Jc [1] http://libcxx.llvm.org/ [2] http://slicer-devel.65872.n3.nabble.com/Mavericks-with-SimpleITK-tt4030687.html -- +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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Change default standard library implementation before used by compiler ?
You could call CMAKE_USER_MAKE_RULES_OVERRIDE before the first project call. Than have that override file set the CXX_INIT flags based on the compiler/OS/current flags. On Tue, Jan 14, 2014 at 4:14 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Folks, For both Slicer and SimpleITK, there is currently no support for the clang c++ standard library new implementation [1] that is now used by default on Maverick. It means that we currently expect our users to build the project by passing the flag: -DCMAKE_CXX_FLAGS_INIT:STRING=-stdlib=libstdc++ as explained in [2] To allow our users to build without explicitly passing flag, what would be recommended approach ? I was thinking about the following and would like to get your inputs / suggestions: 1) Add a compile test so that the flag could be updated before the first call to project()/enable_langage(). Is this possible ? 2) Wrap the project into a superbuild structure ... that could work but would be a ugly hack. Thanks for your help, Jc [1] http://libcxx.llvm.org/ [2] http://slicer-devel.65872.n3.nabble.com/Mavericks-with-SimpleITK-tt4030687.html -- +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://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] RFC: add version to project() call
On Tuesday 14 January 2014, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. I updated the topic on stage, it basically does that now. I haven't updated the test yet. Alex -- 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] RFC: add version to project() call
On Tuesday 14 January 2014, Matthew Woehlke wrote: On 2014-01-14 10:37, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same for PROJECT_VERSION_MAJOR, but this is maybe less likely. I don't think project(Foo) needs to affect Foo_VERSION_* when no VERSION argument is given (but should handle empty VERSION ). It should still handle PROJECT_VERSION_* to ensure consistency with PROJECT_NAME. That may need a policy, but it will be tricky because we need to know if the value came from a previous project() call or a user set() in order to know when to trigger compatibility. Perhaps project(... VERSION ...) can set some cmMakefile variable internally that says the project knows about versions so it is okay project(Foo) calls to unset them in subdirs. Then we won't need any policy because there is no change in behavior without modifying the project to add at least one VERSION to a project() command. While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides to start using project(...VERSION...). Now if B was using PROJECT_VERSION internally, it is broken. (Note that I'm implying that B is e.g. a separate repository that may not be as easy to update/fix as A.) You mean CMakeLists.txt: project(Foo VERSION 1.2.3) ... add_subdir(B) B/CMakeLists.txt: set(PROJECT_VERSION 4.5.6) project(Bar) Indeed. In that case, PROJECT_VERSION will be unset afterwards. If it would be B/CMakeLists.txt: project(Bar) set(PROJECT_VERSION 4.5.6) everything is fine. Alex -- 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] Change default standard library implementation before used by compiler ?
On Tue, 14 Jan 2014 16:14:44 -0500, Jean-Christophe Fillion-Robin said: For both Slicer and SimpleITK, there is currently no support for the clang c++ standard library new implementation [1] that is now used by default on Maverick. It means that we currently expect our users to build the project by passing the flag: -DCMAKE_CXX_FLAGS_INIT:STRING=-stdlib=libstdc++ That seems like a backwards approach. Do Slicer and SimpleITK not build against libc++? If not, what's the reason you want to force libstdc++? Getting VTK and ITK to build against libc++ was not too much work, I imagine it would not be hard to get Slicer and SimpleITK compiling if they are not already. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] RFC: add version to project() call
On 2014-01-14 18:00, Alexander Neundorf wrote: On Tuesday 14 January 2014, Matthew Woehlke wrote: While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides to start using project(...VERSION...). Now if B was using PROJECT_VERSION internally, it is broken. (Note that I'm implying that B is e.g. a separate repository that may not be as easy to update/fix as A.) You mean CMakeLists.txt: project(Foo VERSION 1.2.3) add_subdir(B) B/CMakeLists.txt: set(PROJECT_VERSION 4.5.6) project(Bar) Indeed. In that case, PROJECT_VERSION will be unset afterwards. Exactly. I wanted to point it out, but as that's probably unusual, I would be okay ignoring that case. If it would be B/CMakeLists.txt: project(Bar) set(PROJECT_VERSION 4.5.6) everything is fine. ...until B/C/CMakeLists.txt also calls project() :-). Basically, you (can) get into trouble if you update your project to use project(VERSION) and also have an external sub-project that tries to use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about this use case (having an embedded external project), I suspect it's not actually very common², and anyway there is only a problem when the sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in general, and more so the intersection of the two). Again, given the above, I've no objection to breaking that case, which may well only exist in the hypothetical sense with no 'in the wild' instances actually existing. (¹ Myself included; this thread being a case in point.) (² ...though I do know offhand that ParaView does so with VTK.) -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
