Build instructions don't work

[dietmarkuehl]

The build instructions of the README.md don't work. At least, it is required to get the submodules (as is done by the Makefile):

git submodule update --init --recursive

Also, for the tests I get a message like (I'm building on a Raspberry PI with manually build gcc-14):

Test project /home/kuehl/src/Optional26/.build/gcc-14
      Start  1: OptionalTest.TestGTest
Test not available without configuration.  (Missing "-C <config>"?)
1/82 Test  #1: OptionalTest.TestGTest ...........................***Not Run   0.00 sec

[neatudarius]

@dietmarkuehl , please check latest main after #29 .

[neatudarius]

Feedback gathered from Dietmar: I still needed to dig about with files in the repo.

Status: validated on RPI Linux with gcc-13 and clang-18. Failed for gcc-12. Need to lower cmake version to 3.25.1 and to remove generator from CMakePresets.json. I would be nice to have ./configure; make; make install or cmake --build dir shorthands.

• Test and document on non-Linux systems (e.g., MAC OS, Windows).
• Test and document minimum cmake and compiler versions.
• Test and document symlink to compilers (where should they be installed - e.g. clang++ vs clang++-18).
  • Symlinks for custom compilers.
  • Symlink for c++ tool.
• Test and document dependencies. ninja, make or another Cmake-supported build system currently ninja is enforced, but not clearly documented. Note: ninja is used only for generator in the preset!
• Test and document C++ standard versions.
• Test and document shorthands for cmake --build dir or make equivalent.

[camio]

I would be nice to have ./configure; make; make install

I don't think the additional complexity of supporting that is worth it. CMake alone is fine as a build system for C++ projects IMO.

[neatudarius]

I don't think the additional complexity of supporting that is worth it. CMake alone is fine as a build system for C++ projects IMO.

@camio , agree with you. I think latest main README.md made progress in simplifing the build proccess of the project. We can put more defaults params in the CMakeLists.txt and maybe we can even simplify more. But we need to know if we want to invest or not time in this direction.

@camio , please also check https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153 (linked issue there) - I think we should keep #31 to track docs for what we have on main as a build system and the discourse for eventually changing an approach.

[steve-downey]

I spend a lot of time on support for building packages, and cmake workflow is a constant problem. Presets are an initial attempt to provide better workflow support, but suffer from combinatoric explosion issues if you need more than one path through the entire build. I suggested configure && make && make check && make install somewhat tongue-in-cheek because of how prevalent it became even outside autotools based projects. [For autotools ./configure && make install was usually actually sufficient but you got less feedback about what logical step failed.]

Requiring so many commands to do common actions, and in the right order, is a failure in ergonomics, and "your IDE will fix it" is not much better. "You just have to remember" is an admission that people won't and you will blame them for it. Note: I really am assuming good will on everyone's part here! The common state for C++ projects is awful, and that's not the worst problem most C++ projects have, so we live with it and work around it.

re: tool versions - It's too bad there isn't an existing CppPI, but we might considering leveraging PyPi. We probably will need to anyway for linting tools? PyPI has cmake, ninja [w/jobserver patch], clang-format, clang-tidy, as well as cmakelint, cmake-format, and others. The big advantage is that by installing in a virtual env the project doesn't have to rely on OS provided tools or require local installs that have cross-project impact.

I'll make some notes on the linked discourse, too.

Getting a better Out-Of-Box experience should be the goal here.
Even if it's a moderate sized block of shell commands to c/p from the README.md.

[dietmarkuehl]

I would be nice to have ./configure; make; make install

I don't think the additional complexity of supporting that is worth it. CMake alone is fine as a build system for C++ projects IMO.

I'm not disagreeing, assuming the cmake works. It may still be cute to effectively pretend (although I'd try to forward various arguments like --prefix to cmake):

$ cat configure
#!/bin/sh
echo configured

$ cat Makefile
.PHONY: default install
default:
cmake

install:
cmake