Fix CMake configuration for CONTOUR_FRONTEND_GUI=OFF to still build contour binary, but without GUI.

[christianparpart]

Closes #1780.

[barracuda156]

@christianparpart Thank you. Will it be possible to build non-GUI one without Qt? Common libraries can be built without it, but I am unsure about the executable.

[christianparpart]

@christianparpart Thank you. Will it be possible to build non-GUI one without Qt? Common libraries can be built without it, but I am unsure about the executable.

without Qt entirely? We're using some of Qt features in non-GUI mode though.

I could make it link to non-GUI libraries (as it should), but libraries, such as QtCore (non-GUI, purely core library functionality) would be inconvenient to get rid of. Would that fit?

[barracuda156]

Do you mean the executable or libs?

Libs have built for me from https://github.com/macos-powerpc/powerpc-ports/blob/5a6c4bbe4c920672e4116073ef5ccb53cb353ec4/sysutils/contour/Portfile with two ObjC-related patches (nothing about Qt), but executable does not build.

It will be much easier, I guess, if dependencies are reduced to QtCore, since a) it is likely easier to port to Qt4 and b) there is a higher chance that Qt6 Core is fixed than the whole of Qt6. So it makes sense still.

[christianparpart]

So in my local non-GUI build (On Fedora Linux!), it currently looks like this:

ldd out/linux-clang-debug/src/contour/contour

christianparpart@fedora ~/p/contour (fix/cmake-contour-non-gui)> ldd ./out/linux-clang-debug/src/contour/contour
        linux-vdso.so.1 (0x00007f25b04af000)
        libQt6Core.so.6 => /lib64/libQt6Core.so.6 (0x00007f25afc00000)
        libyaml-cpp.so.0.8 => /lib64/libyaml-cpp.so.0.8 (0x00007f25b0430000)
        libssh2.so.1 => /lib64/libssh2.so.1 (0x00007f25b03e5000)
        libutempter.so.0 => /lib64/libutempter.so.0 (0x00007f25b03e1000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f25af800000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f25b02eb000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f25afbd4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f25af60c000)
        libicui18n.so.77 => /lib64/libicui18n.so.77 (0x00007f25af200000)
        libicuuc.so.77 => /lib64/libicuuc.so.77 (0x00007f25aee00000)
        libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f25afb11000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f25af0aa000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f25afaee000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f25aecda000)
        libdouble-conversion.so.3 => /lib64/libdouble-conversion.so.3 (0x00007f25afad8000)
        libb2.so.1 => /lib64/libb2.so.1 (0x00007f25b02df000)
        libpcre2-16.so.0 => /lib64/libpcre2-16.so.0 (0x00007f25af00d000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f25ae600000)
        libssl.so.3 => /lib64/libssl.so.3 (0x00007f25aebef000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f25b04b1000)
        libicudata.so.77 => /lib64/libicudata.so.77 (0x00007f25ac600000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f25aeb44000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f25afacc000)
        libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f25af5b4000)

[barracuda156]

So in my local non-GUI build (On Fedora Linux!), it currently looks like this:

Thank you! I think the only complication for us is with Qt (for actual GUI OpenGL may turn a problem, if 2.0 is unsupported, but that’s irrelevant for CLI). All other libs – adjusted for what macOS needs – can be built with no issues.
With Qt6 it is a bit tricky, since X11 backend is broken for all macOS in upstream, but it should be fixable. I can check it this can work on arm64 first (where I have hacked Qt6 base to build as X11-only), and once that works, make another attempt at fixing it for powerpc.