update cmake to 3.13.2

[autc04]

The previously provided cmake 3.6.3 is over two years old now, so here's an upgrade.

The good news:

• It seems to work.

The bad news:

• It now needs a C++11 compiler.
• It needed some patches, disabling the use of some features of more modern macOS incarnation, that the current cmake source code just assumes to be there.

[mistydemeo]

We've upgraded to 3.9.6 (the last version to build with the system compilers). I'll see if I can get this working with newer compilers.

[glebm]

It'd be cool to get a more modern CMake.
FetchContent appeared in 3.11 and a lot of software makes use of it these days.

PS: I'm here because a user on the DevilutionX discord has asked for help compiling it for PPC macOS 10.4. Then I found this repo via Google.

[sevan]

It'd be cool to get a more modern CMake. FetchContent appeared in 3.11 and a lot of software makes use of it these days.

PS: I'm here because a user on the DevilutionX discord has asked for help compiling it for PPC macOS 10.4. Then I found this repo via Google.

There's no reason why we couldn't have a another formula for a more recent version of cmake.
The reason it is currently at 3.9.6 is because as Misty pointed out, that version is the most recent that can be compiled with the system's compiler. After that, you'll need a compiler with C++11 support and on a PowerPC mac you're looking at 24 hours+ to build GCC 5 or 7. So it's a bit of a detour. :)

[glebm]

If that formula were installable with something as simple as brew install cmake-latest, that'd be good to point users to!

Anyone willing to install this on a PPC mac can probably wait 24 hours. For science.

[glebm]

@AJenbo even has a PPC mac so if this works maybe we could even provide a PPC mac release of DevilutionX

[mistydemeo]

I guess we could ensure the dependency on GCC gets properly specified as a runtime dep, then make sure both the compiler and cmake get binary builds on as many OSs as possible... that way people are just spending disk space, not hours/days of compiling time.

Sevan, have you checked if GCC 5/7 is the minimum required version?

[AJenbo]

I personally don't have a lot of time (though there will be a blank space in the next two weeks), but the 700Mhz G4 iMac is just sitting there so if you can make it easy for me I'm happy to turn it on and let it process things for a few days.

[sevan]

Sevan, have you checked if GCC 5/7 is the minimum required version?

From memory, initial C++11 support in later releases of 4.x but you need at least 5. Will give it a try tomorrow and report back.

[AJenbo]

GCC 4.8 I think has decent support

[sevan]

cmake has a bootstrap stage where the cmake binary is created and then a build stage where it's used to build the rest of the project.

I got quite far into the bootstrap stage of the very latest release of cmake (v3.31.0) on Tiger with GCC 5 but hit issues with libuv as Tiger isn't supported.
I stepped back to building the latest version of v3.13 (v3.13.5) which this pull request is based on. I fought libuv and completed the build stage but then came tumbling down as it was expecting a libuv library to be provided outside of the bootstrap env ("use system-installed libuv library")
All very promising.
So to answer the question, both versions of cmake which I attempted to build required C++17 support and GCC 5's level of support seemed sufficient. Just need to fix the libuv formula in Tigerbrew and patch cmake in a couple of places and hopefully that will get cmake build & installed on Tiger.

[AJenbo]

Mean while I got stuck here with this PR:

==> ./bootstrap --prefix=/usr/local/Cellar/cmake/3.13.2 --no-system-jsoncpp --system-libs --parallel=1 --datadir=/share/cmake --docdir=/share/doc/cmake --mandir=/share
Last 15 lines from /Users/andersjenbo/Library/Logs/Homebrew/cmake/22.bootstrap:
-- Found LibArchive: /usr/local/opt/libarchive/lib/libarchive.dylib (found suitable version "3.7.4", minimum required is "3.1.0") 
-- Could NOT find LibUV: Found unsuitable version "", but required is at least "1.10.0" (found LibUV_LIBRARY-NOTFOUND)
CMake Error at CMakeLists.txt:552 (message):
  CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!
Call Stack (most recent call first):
  CMakeLists.txt:685 (CMAKE_BUILD_UTILITIES)


-- Configuring incomplete, errors occurred!
See also "/tmp/cmake20241112-5866-1ltbnes/cmake-3.13.2/CMakeFiles/CMakeOutput.log".
See also "/tmp/cmake20241112-5866-1ltbnes/cmake-3.13.2/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------

READ THIS: https://github.com/mistydemeo/tigerbrew/wiki/troubleshooting

These open issues may also help:
update cmake to 3.13.2 https://github.com/mistydemeo/tigerbrew/pull/620
mariadb won't build on 10.5.8; cmake logs don't exist at given location https://github.com/mistydemeo/tigerbrew/issues/183

[sevan]

Same place for me. :)
You could try brew install libuv and then try to build cmake again.

[AJenbo]

libtool: compile:  /usr/bin/gcc-4.0 -std=gnu99 -DPACKAGE_NAME=\"libuv\" -DPACKAGE_TARNAME=\"libuv\" -DPACKAGE_VERSION=\"1.7.4\" "-DPACKAGE_STRING=\"libuv 1.7.4\"" -DPACKAGE_BUGREPORT=\"https://github.com/libuv/libuv/issues\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libuv\" -DVERSION=\"1.7.4\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DHAVE_LIBKVM=1 -DHAVE_LIBPTHREAD=1 -I. -I./include -I./src -I./src/unix -I/usr/local/opt/libtool/include -F/usr/local/Frameworks -Os -w -pipe -mcpu=7450 -faltivec -mmacosx-version-min=10.4 -arch ppc -fvisibility=hidden -g -std=gnu89 -pedantic -Wall -Wextra -Wno-unused-parameter -D_DARWIN_USE_64_BIT_INODE=1 -D_DARWIN_UNLIMITED_SELECT=1 -Os -w -pipe -mcpu=7450 -faltivec -mmacosx-version-min=10.4 -arch ppc -fvisibility=hidden -g -std=gnu89 -pedantic -Wall -Wextra -Wno-unused-parameter -c src/threadpool.c  -fno-common -DPIC -o src/.libs/libuv_la-threadpool.o
In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:46,
                 from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:25,
                 from src/unix/internal.h:52,
                 from src/threadpool.c:25:
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OpenTransportProviders.h:108: error: parse error before numeric constant
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OpenTransportProviders.h:116: error: parse error before numeric constant
make: *** [src/libuv_la-threadpool.lo] Error 1

[AJenbo]

This happens even if i roll back to libuv 1.1.0 and since it looks to be an issue with the CoreServices.framework (TCP_NODELAY being first defined using #define TCP_NODELAY 0x01 and then again as an enum in the header that the error points to) I'm not sure how to deal with it.

[sevan]

I've not tested the patch proposed in this pull request but they proposed

iff -u -r cmake-3.13.2/Utilities/cmlibuv/src/unix/darwin-proctitle.c cmake-3.13.2-patched/Utilities/cmlibuv/src/unix/darwin-proctitle.c
 --- cmake-3.13.2/Utilities/cmlibuv/src/unix/darwin-proctitle.c	2018-12-13 12:57:42.000000000 +0100
 +++ cmake-3.13.2-patched/Utilities/cmlibuv/src/unix/darwin-proctitle.c	2018-12-16 16:01:36.000000000 +0100
 @@ -29,6 +29,9 @@
  #include <TargetConditionals.h>

  #if !TARGET_OS_IPHONE
 +#undef TCP_NODELAY
 +#undef TCP_MAXSEG
 +#undef TCP_KEEPALIVE
  # include <CoreFoundation/CoreFoundation.h>
  # include <ApplicationServices/ApplicationServices.h>
  #endif

Worth a shot, just to bodge it forward (I didn't have to make such a change on my build attempt with v3.13.5)

[AJenbo]

@sevan adding this at line 148 fixes the issue:

--no-system-libuv

[sevan]

If you manage to port to Tiger, is it worth adding autoconf support to your projec so that on such legacy systems you only need to show up with a modern compiler to move forward? not sure the benefits of modern cmake are realised on such systems with a legacy toolchain. :)

[glebm]

It'd be extremely difficult to port and maintain our very complex CMake project to autoconf.

[sevan]

It'd be extremely difficult to port and maintain our very complex CMake project to autoconf.

understood. :)

[glebm]

So I found this image:
https://archive.org/details/mac-osx-tiger-10.4-ppc-installed-qcow2-image

If it works, it'd probably be a lot faster to compile software in a VM?
Then there'd be less reason to worry about the long gcc bootstrap times.

[sevan]

So I found this image: https://archive.org/details/mac-osx-tiger-10.4-ppc-installed-qcow2-image

If it works, it'd probably be a lot faster to compile software in a VM? Then there'd be less reason to worry about the long gcc bootstrap times.

That's cheating and deters from sourcing a G5 based system of some form to build on. ;) j/k

[sevan]

There's a draft pull request for a fairly recent version of libuv which builds on Tiger in #1202 should you need it.

[AJenbo]

@sevan We can now build newer versions of DevilutionX, but it fails to link with the following error:

/usr/bin/ld: unknown flag: -no_compact_unwind

Is this something you are familiar with?

[mistydemeo]

Do you know what's specifying that flag? Tiger's ld doesn't support it, and you may just be able to remove it from whatever in your build is adding it. Otherwise, the ld64 formula in Tigerbrew provides a newer linker that supports that flag. You can install that package, then enable it in your build by setting LD to /usr/local/opt/ld64/bin/ld and adding -B/usr/local/opt/ld64/bin/ to your LDFLAGS.

[AJenbo]

30 hours of bisecting and it turns out to be because of set(CMAKE_OSX_DEPLOYMENT_TARGET "10.12.0") being in our CMakeList.txt file :D

[AJenbo]

Thank you for helping with this.

... so if anyone wants to help get CMake 3.15 and GCC 10 up and running then we should be good for the next major release as well 😅

[sevan]

Very cool :)

[sevan]

... so if anyone wants to help get CMake 3.15 and GCC 10 up and running then we should be good for the next major release as well 😅

Now that there's a recent version of libuv built, I can take a look at the latest release of CMake again over the weekend.
I managed to get GCC 13 as a cross-compiler built a while back (PR #1063) using GCC 7 so there's hope but not promising anything.