cmake: upgrade to 3.0.0

[mojca (Mojca Miklavec)]

This is a preliminary request to test cmake 3.0.0-rc1 before that version gets officially released (and to upgrade to 3.0.0 once it gets released).

[mojca (Mojca Miklavec)]

I went through the patches, but I wasn't sure about the Qt patch, so that one needs a review.

[cooljeanius (Eric Gallager)]

Seeing as 3.0.0 is a major version bump, are there any API changes that would require modifications to the cmake portgroup as well?

[cooljeanius (Eric Gallager)]

Cc Me!

[mojca (Mojca Miklavec)]

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.

[cooljeanius (Eric Gallager)]

Replying to 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.

OK, sounds good. Hey by the way while you are working on the CMake port, could you also take a look at #41817 for me?

[mojca (Mojca Miklavec)]

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.

[cooljeanius (Eric Gallager)]

Replying to 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.

I am not subscribed to the CMake mailing list and would prefer not to have to subscribe to it just to bring up that one issue... are you subscribed to it?

[cssdev]

I haven't looked at the impact of the changes, but should we consider separate cmake2 and cmake3 ports to allow trying both?

[mojca (Mojca Miklavec)]

Do you mean installing both at the same time or both conflicting with each other?

I don't think that there is a need to do that and I smell a lot of problems/complications related to side-by-side installations of cmake2 + cmake3, but if you would like to allow it, feel free to go forward and try.

It might be nice to provide a temporary port cmake-devel conflicting with cmake, just until cmake 3 gets released and then remove it. But I cannot imagine having both installed side-by-side in the long run.

[mojca (Mojca Miklavec)]

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.

[mojca (Mojca Miklavec)]

I added a patch for RC2.

[mkae (Marko Käning)]

Cc Me!

[mojca (Mojca Miklavec)]

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?

[mojca (Mojca Miklavec)]

Committed in r121104.

One warning on 10.6 includes #43924.

To answer my own question about lbistdc++: it was committed in r110452 by jeremyhu as "cmake: Don't use libc++ on Lion, even if we were told to." I can confirm that the build against libc++ fails.

[mojca (Mojca Miklavec)]

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)