#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by mojca@…): I went through the patches, but I wasn't sure about the Qt patch, so that one needs a review. -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by mojca@…): The PortGroup needs a bunch of changes actually. But not because of the version bump. There are things that MacPorts does suboptimally, including: * always specifying the architecture, so that Fortran compiler gets `-arch x86_64` flag and subsequently nothing works (also CMake's problem, but MacPorts could avoid that) * don't add `-I/opt/local/include` to `CXXFLAGS` * automatically build out-of-source (maybe that's something that should be supported globally in MacPorts) * not so much a problem of the PortGroup, but maybe we need more patches to allow easier discovery of different packages (FindX11 still found files from /usr in some cases for example) * etc. Anyway, I'll use that version from now on and I'll see if I bump into any problem. If any problems arise, I suspect the problems would be in CMake files provided by individual software, not so much with the PortGroup. -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X

#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by mojca@…): I totally agree with the change, but I consider that an inherent flaw in CMake, something worth asking about on the CMake mailing list. Whether or not CMake upstream actually does anything about it – I'm not an official maintainer of CMake, so I don't dare making the change without css's consent. I could use maintainer timeout, but at least some "go ahead" or "please wait/don't do it" would help before doing these changes. -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X

#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by css@…): I haven't looked at the impact of the changes, but should we consider separate cmake2 and cmake3 ports to allow trying both? -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X

#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by mojca@…): One "issue" I'm seeing is the following: {{{ CMake Warning (dev) at CMakeLists.txt:5 (PROJECT): Policy CMP0025 is not set: Compiler id for Apple Clang is now AppleClang. Run "cmake --help-policy CMP0025" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Converting C compiler id "AppleClang" to "Clang" for compatibility. This warning is for project developers. Use -Wno-dev to suppress it. }}} From `${prefix}/share/cmake-3.0/Help/policy/CMP0025.rst`: {{{ CMP0025 ------- Compiler id for Apple Clang is now AppleClang. CMake >= 3.0 recognize that Apple Clang is a different compiler than upstream Clang and that they have different version numbers. CMake now prefers to present this to projects by setting CMAKE_<LANG>_COMPILER_ID to "AppleClang" instead of "Clang". However, existing projects may assume the compiler id for Apple Clang is just "Clang" as it was in CMake < 3.0. Therefore this policy determines for Apple Clang which compiler id to report in CMAKE_<LANG>_COMPILER_ID after <LANG> is enabled by the project() or enable_language() command. The OLD behavior for this policy is to use compiler id "Clang". The NEW behavior for this policy is to use compiler id "AppleClang". This policy was introduced in CMake version 3.0. CMake version |release| warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly. }}} But this needs to be reported to individual projects upstream and it doesn't seem to cause any problems. So far I didn't experience any troubles using CMake 3.0. -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X

#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by mojca@…): CMake 3.0 has been released. I attached a patch for the upgrade. Unrelated to the upgrade itself: I also removed a check for existence of `configure.cxx_stdlib` (now that MacPorts 2.3.0 is out), but I'm actually curious why the following code is needed at all: {{{ platform darwin 11 { # TODO: Figure out why using libc++ fails. # Since nothing links against cmake and cmake is just using # the STL, we're safe to force libstdc++ configure.cxx_stdlib libstdc++ } }}} Isn't `libsttdc++` default on darwin 11 anyway? -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X

#42654: cmake: upgrade to 3.0.0 ----------------------+------------------- Reporter: mojca@… | Owner: css@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: cmake | ----------------------+------------------- Comment (by mojca@…): The failure when building `cmake` with `libc++` on 10.7 is: {{{ [ 25%] Built target cmcurl gmake -f Utilities/cmcurl/CMakeFiles/LIBCURL.dir/build.make Utilities/cmcurl/CMakeFiles/LIBCURL.dir/depend gmake[2]: Entering directory '/path/to/cmake-3.0.0' cd /path/to/cmake-3.0.0 && /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_depends "Unix Makefiles" /path/to/cmake-3.0.0 /path/to/cmake-3.0.0/Utilities/cmcurl /path/to/cmake-3.0.0 /path/to/cmake-3.0.0/Utilities/cmcurl /path/to/cmake-3.0.0/Utilities/cmcurl/CMakeFiles/LIBCURL.dir/DependInfo.cmake --color= gmake[2]: Leaving directory '/path/to/cmake-3.0.0' gmake -f Utilities/cmcurl/CMakeFiles/LIBCURL.dir/build.make Utilities/cmcurl/CMakeFiles/LIBCURL.dir/build gmake[2]: Entering directory '/path/to/cmake-3.0.0' Linking C executable LIBCURL cd /path/to/cmake-3.0.0/Utilities/cmcurl && /path/to/cmake-3.0.0/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/LIBCURL.dir/link.txt --verbose=1 /usr/bin/clang -pipe -Os -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 CMakeFiles/LIBCURL.dir/Testing/curltest.c.o -o LIBCURL libcmcurl.a -lidn ../cmzlib/libcmzlib.a ld: archive has no table of contents for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Utilities/cmcurl/CMakeFiles/LIBCURL.dir/build.make:87: recipe for target 'Utilities/cmcurl/LIBCURL' failed gmake[2]: *** [Utilities/cmcurl/LIBCURL] Error 1 gmake[2]: Leaving directory '/path/to/cmake-3.0.0' CMakeFiles/Makefile2:1364: recipe for target 'Utilities/cmcurl/CMakeFiles/LIBCURL.dir/all' failed gmake[1]: *** [Utilities/cmcurl/CMakeFiles/LIBCURL.dir/all] Error 2 gmake[1]: Leaving directory '/path/to/cmake-3.0.0' Makefile:147: recipe for target 'all' failed gmake: *** [all] Error 2 }}} {{{ $ /usr/bin/clang -v -pipe -Os -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 CMakeFiles/LIBCURL.dir/Testing/curltest.c.o -o LIBCURL libcmcurl.a -lidn ../cmzlib/libcmzlib.a Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin11.4.2 Thread model: posix "/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.7.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -o LIBCURL -lcrt1.10.6.o -L/opt/local/lib -search_paths_first -headerpad_max_install_names -headerpad_max_install_names CMakeFiles/LIBCURL.dir/Testing/curltest.c.o libcmcurl.a -lidn ../cmzlib/libcmzlib.a -lSystem /usr/bin/../lib/clang/4.2/lib/darwin/libclang_rt.osx.a ld: archive has no table of contents for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) }}} -- Ticket URL: <https://trac.macports.org/ticket/42654#comment:15> MacPorts <http://www.macports.org/> Ports system for OS X