cmake @3.16.0: error: no matching constructor for initialization of 'const std::vector<ExpectedSpec>'

[lemzwerg (Werner Lemberg)]

:info:build /opt/local/var/macports/build/_opt_macports_macports-ports_devel_cmake/cmake/work/cmake-3.16.0/Tests/CMakeLib/testCTestResourceSpec.cxx:14:40: error: no matching constructor for initialization of 'const std::vector<ExpectedSpec>'

Full log file attached.

[kencu (Ken)]

It's going to completely blow bootstrapping plans, but FYI cmake does build on 10.7 with clang-9.0, at least.

[kencu (Ken)]

I have a cmake39 port, last that did not require c++11, that could become cmake-bootstrap if we need to go that route.

​https://github.com/kencu/myports/tree/master/devel/cmake39

I guess we need to pay closer attention to the devel version; we should have seen this coming.

[kencu (Ken)]

see also #59780

[kencu (Ken)]

If some c++ genius comes along, perhaps we can figure out how to change the troublesome <vector> code to something that clang-3.4 can understand -- AFAICT it is something to do with the default allocator, and it was fixed in clang-3.7.

I did figure out how to better control the cmake build using the bootstrap script, and you can pass in cmake arguments in the normal way to the bootstrap cmake that is building the final cmake to be installed. That lets you turn off the piece of code that is erroring out, and with that, cmake does build and install with clang-3.4, so our current bootstrapping will continue to work.

This little bit does that (and also, with a small bit of work, we could fully control the cmake build, and pass in all kinds of different, potentially useful, cmake defines that currently aren't able to be used).

$ diff -u Portfile `port file cmake`
--- Portfile	2019-12-05 20:34:42.000000000 -0800
+++ /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/cmake/Portfile	2019-12-05 20:33:27.000000000 -0800
@@ -122,6 +122,8 @@
 # system libuv is the default as of 20160830 (g320f5)
 depends_lib-append  path:lib/pkgconfig/libuv.pc:libuv
 
+configure.cmd ./bootstrap
+
 configure.env-append \
                     CMAKE_PREFIX_PATH=${prefix} \
                     CMAKE_INCLUDE_PATH=${prefix}/include/ncurses \
@@ -139,6 +141,7 @@
 # Clang 3.4 works. But Clang 3.7 doesn't work.
 if {${os.platform} eq "darwin" && ${os.major} == 11 && ${configure.cxx_stdlib} eq "libc++"} {
     compiler.whitelist macports-clang-3.4
+    configure.post_args -- -DBUILD_TESTING=OFF
 }
 
 platform darwin {
@@ -173,7 +176,7 @@
                     --no-system-librhash
 
 configure.universal_args
-configure.post_args
+#configure.post_args
 
 # CMake's configure script doesn't recognize `--host`.
 array set merger_host {i386 {} x86_64 {} ppc {} ppc64 {}}

[kencu (Ken)]

One potential solution to this is <​https://github.com/macports/macports-ports/pull/5946>.

[ken-cunningham-webuse]

In ac9b9592f4e0a909cf85797fe4f601cbade82f7d/macports-ports (master):

cmake: fix build with clang-3.4

enable existing mechanism to pass -DCMAKE arg to cmake during build
disable certain cmake self-tests which currently don't build with clang-3.4
allows bootstrapping with clang-3.4 -> cmake -> clang-3.7
closes: #59782

[iEFdev]

Replying to kencu:

This little bit does that (and also, with a small bit of work, we could fully control the cmake build, and pass in all kinds of different, potentially useful, cmake defines that currently aren't able to be used).

$ diff -u Portfile `port file cmake`
// ... //

Thanks Ken! That one worked for me. Applied the changes from that diff in a local port, for now.

# There's no “CC Me!” in the ticket header?

[lemzwerg (Werner Lemberg)]

Yeah, thanks a lot! It worked just fine.