Create a CMake configuration to build Elektroid on Windows without MSYS2

[dagargo]

After discarding #149, it might be a better idea to try creating a CMake configuration for Windows only.

Configuration will be simplified by considering this:

• Only GUI is needed (no CLI).
• RtMIDI and RTAudio will be used.

[oldrobotdev]

I put together a CMake build for this and have it working end to end. It sits alongside the autotools build rather than replacing it: same sources and pkg-config deps with the same optional switches, the config.h generation, the gettext catalogs, the CUnit tests wired into ctest, and the install rules. It configures, builds, and passes ctest (12/12) on macOS with the RtMidi and RtAudio backends, which is the same backend set Windows uses, so the Windows-without-MSYS2 case is just the default there.

One portability snag I ran into: src/connectors/logue.c includes <asm-generic/errno-base.h>, which is Linux-only and breaks the build on Windows and macOS. ENOENT is the only symbol it uses and that comes from standard <errno.h>, so it is a one-line fix I kept as its own commit.

Glad to open a PR if you'd like it. Would you rather have the CMake build as a faithful cross-platform mirror, which is what I have, or scoped down to Windows only?

[dagargo]

First of all, thank you so much for the CMake configuration files. I tried a couple of times and getting into it was complicated and didn't have enough time to solve the issues that I had. Adding this to Elektroid would be awesome!

Including <asm-generic/errno-base.h> was a mistake. Sometimes, Zed editor adds these includes and I forgot to delete them at some point. I've checked the compilation on Linux and MSYS2 just without that include and it works. So I've pushed 955da00 to fix this. Thanks for the heads up, BTW.
Regarding the need for <errno.h>, it has to be included transitively so there's no need for that unless I'm wrong. I'll check this again when testing the CMake building process.

I'd really like the PR for the full cross-platform for now. I'm still unsure about migrating completely to CMake or have a dual autotools-CMake project. Very likely, migrating everything is better but I have almost no experience with CMake so I'm gonna merge your PR into a experimental branch called feat-cmake and test it and play a bit with it before fully deciding what to do and merging it into master.

Would you mind explain here how to properly build it? Or is it just the usual?

Also, I hope you don't mind discussing here the possible issues, improvements and how to document all this.

[oldrobotdev]

It's the usual out-of-source CMake, same three steps everywhere:

cmake -S . -B build
cmake --build build -j
cmake --install build

Tests run with ctest --test-dir build --output-on-failure. The options map one-to-one onto the configure flags (-DELEKTROID_CLI_ONLY=ON for CLI_ONLY=yes, plus -DELEKTROID_RTMIDI, -DELEKTROID_RTAUDIO, -DELEKTROID_NLS=OFF, -DELEKTROID_BUILD_TESTS=OFF), full table in the README the PR adds. Deps come through pkg-config, and RtMidi/RtAudio are the defaults everywhere but Linux, same as autotools.

Windows without MSYS2 is the one that differs: deps from vcpkg, and point CMake at its toolchain file.

vcpkg install gtk3 rtmidi rtaudio libsndfile libsamplerate libzip zlib json-glib rubberband gettext
cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=C:/path/to/vcpkg/scripts/buildsystems/vcpkg.cmake
cmake --build build --config Release

I built and ran ctest (12/12) on macOS, which uses the same RtMidi and RtAudio backends as the Windows build. Haven't built on Linux or real Windows myself, so those are worth checking when you try the branch.

On explicit vs transitive errno.h: I'd only bother with the explicit include if some toolchain didn't pull it in on its own, but your MSYS2 build shows it does, so I left it as you have it. And on docs, README.md is generated from docs/, so I added the CMake section to docs/installation.md too and kept it identical, though it's worth a make to confirm the README regenerates the same.

[dagargo]

Just wanted to say that I've successfully run and installed Elektroid on Linux and macOS with CMake. This is so great!

I'll try installing it on Windows later today and report back.

[dagargo]

Compilation on Windows gave a lot of errors. I've fixed many with a few commits, which included mainly removing types, constants and dependencies that are not availalable on Windows. It looks very promising now but there are still a few things to address.

Due to these, I'm considering removing the CLI entirely on Windows, which will solve most of them due to signals and the options reading library.

For anyone reading this, there is an option that is CLI_ONLY that skips the building of the GUI. Shouldn't it be better to have a BUILD_CLI that will be ON for macOS and Linux and be disabled entirely on Windows at least for now? For completeness, we could have also BUILD_GUI.

[oldrobotdev]

Yeah, I'd go with the two-toggle version. BUILD_GUI and BUILD_CLI as independent options is more honest than CLI_ONLY, which can only turn the GUI off and has no way to say GUI-only. With two flags Windows just defaults to GUI on and CLI off, and a headless Linux box can still build CLI only.

For defaults I'd have BUILD_GUI ON everywhere, BUILD_CLI ON on Linux and macOS and OFF on Windows, plus a check that errors if both are off so configure fails loudly instead of building nothing.

Autotools still speaks CLI_ONLY though, so the two build systems drift on option names. Since CMake is the experimental branch and you're leaning toward it being the eventual path, I think that drift is fine. If you'd rather keep them aligned for now, I can map CLI_ONLY onto the new flags so both keep working.

I can put up a follow-up PR against feat-cmake with the two options and the Windows defaults, if you'd rather not thread it into the fixes you're already making.

[dagargo]

I've pushed a few more commits and we're almost there.

I've added the BUILD_CLI and BUILD_GUI parameters to both autoconf and CMake but it seems not no work in CMake and builds the CLI anyway. It doesn't have an OFF value on Windows by default but passing -DELEKTROID_BUILD_CLI=OFF should have done it. If you could take a look at this, I'd be great.

I've noticed a couple of additional issues.

• On windows, there is a linking issue against pthread.lib (fatal error LNK1181).
• On Linux, there are few compilation warnings. I guess the compilation options are different or more restrictive.

I'll keep on investigating these issues during the following days.

[dagargo]

ELEKTROID_BUILD_CLI and ELEKTROID_BUILD_GUI work with CMake.

I'm trying to change everything in parallel so that when I decide to remove the autotools support it will work at that point in the same way CMake will do.

I've merged the changes into the last commit so I've rebased the feat-cmake branch.

[oldrobotdev]

Took a look at the BUILD_CLI one. On my end the guard works: I configured feat-cmake fresh with -DELEKTROID_BUILD_CLI=OFF and elektroid-cli isn't created, only the elektroid GUI target is. Same result reconfiguring an existing build dir that started on the default: the cache flips to OFF and the target drops. Every reference to elektroid-cli is gated (the add_executable, the install, the man page, and the integration tests via if(TARGET elektroid-cli)), so with a clean build dir it shouldn't build.

My guess is a leftover binary: if the dir was configured and built once with the default, build/src/elektroid-cli stays on disk after you reconfigure with OFF, since CMake doesn't remove old artifacts. A fresh build dir, or cmake --build build --clean-first, should confirm it.

For the Windows default, the option is ON everywhere right now. To get it off on Windows by default you can key the default off WIN32:

if(WIN32)
  set(_cli_default OFF)
else()
  set(_cli_default ON)
endif()
option(ELEKTROID_BUILD_CLI  "Build CLI"  ${_cli_default})

Happy to send that as a small PR against feat-cmake if useful. I can also take a look at the pthread.lib link error if you want a hand.

[dagargo]

First of all, thanks for giving it a try. 🙂

Everything looks quite good then except that issue you're mentioning but I don't quite understand it. Could you explain it again?

I'll add the default Windows options tomorrow, try it out and report back.

Regarding pthread.lib, some help would come very handy. I spent some time trying to figure out how to properly set up everything to build the binary but all my attempts have been unsuccessful.

[dagargo]

I've just tested your suggestion on how to set ELEKTROID_BUILD_CLI to OFF on WIN32 and pushed a commit. See d30abcb.

[oldrobotdev]

That's exactly it, thanks for testing and pushing it. I can't reproduce a Windows/MSVC build on my end so I can't chase the pthread.lib error directly, but LNK1181 on pthread.lib usually traces back to a pkg-config .pc file passing -lpthread, which MSVC can't turn into a real lib. If you narrow down which target's link line pulls it in, I'm glad to help work out the fix.

[dagargo]

I've managed to compile elektroid! 🎉

There are still some issue though. I'm putting everything here so we can solve all of them,
For reference, these are the instructions I'm using right now.

cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=C:\Users\user\\git\vcpkg\scripts\buildsystems\vcpkg.cmake -DCMAKE_INSTALL_PREFIX="C:\Program Files (x86)\elektroid" -DELEKTROID_BUILD_TESTS=OFF
cmake --build build --config Debug
Sudo cmake --install build --config Debug

• On Linux, there are many compilation warnings. I still need to take a look at this but I suspect It's due to using clang instead of gcc. I'd rather it be gcc. Edit: The issue was in the default options passed to the compiler. See comment below.
• On Windows, it compiles but doesn't run because elektroid can't find the libraries (dll) needed.
• On Windows, it requires Debug instead of Release because of some weird dependency of RtMidi. I'd like to have this confirmed but it seems to be a requirement.
• On Windows, it is needed to set CMAKE_INSTALL_PREFIX. Wouldn't it be better to have a default directory set to C:\Program Files (x86)\elektroid? What's the usual approach?
• On Windows, tests can't be compiled so -DELEKTROID_BUILD_TESTS=OFF is needed. Cunit is installed but it's not listed in the dependencies. This needs to be fixed and documented or skipped entirely.

Despite all the remaining things, this looks really nice and very likely it would be running in a matter of days. Still unsure about replacing autotools or having a dual project.