Provide cmake build system?

[waywardmonkeys]

A cmake build system could possibly replace the autoconf-based build system.

This would be able to generate project files for various IDEs, integrate with something like vcpkg, generates commands.json to make it easier to drive clang-tidy and the static analysis tools, etc.

This could be pretty self-contained and would be fewer files than the autoconf system. Perhaps it could even replace the main / primary build system!

[rptb1]

The MPS primary build system is cc. See "Compiling for production". 😄

The reasons for using autoconf are:

1. make it easy for people who expect ./configure && make as used in many classic FOSS projects
2. to drive CI and automated tools (see design.mps.tests.ci.run.posix)

The configure script outputs a message saying it's not really the thing to use. It's just a front end to the real "system" which is in GNU Make, NMAKE, or Xcodebuild. See "Building the MPS for development".

So we could consider replacing GNU Make, NMAKE, and Xcodebuild with cmake. Autoconf is a red herring.

[lassik]

Not sure whether this is relevant, but cmake is written in C++. Hence a C++ compiler is required to compile cmake for each target platform. (AFAIK cmake must be run on the build platform; it cannot generate portable scripts like GNU automake.) This might make it more difficult to work with some embedded or experimental targets, but perhaps it will not.

[rptb1]

a C++ compiler is required to compile cmake ... more difficult to work with some embedded or experimental targets

This brings up a useful requirement to define.

Whatever "make" we're using needs to be available to developers of the MPS on the "supported" platforms. GNU Make, NMAKE, and Xcodebuild together meet that requirement.

But we can ensure things stay easy for developers porting to platforms that don't have many tools.

From the beginning it's been a design principle that the MPS can be built by a command like:

cc -c -o mps.o -D<something>... <source>.c...

so that we don't start getting tangly nests of dependencies on tools and the MPS stays easy to port.

That in turn means that people should easily be able to cook up some alternative where they need it.

If we introduce a tool like cmake for convenience, keep that build principle, and give a few instructions, then I think things could work out well.

[rptb1]

a design principle that the MPS can be built by a command like

This is defined in detail in design.mps.config.build.cc.

That in turn means that people should easily be able to cook up some alternative where they need it.

And this point is covered in design.mps.config.build.rat, which says:

The simplicity of the build function has also made it easy to set up builds using NMAKE (DOS), MPW (Macintosh), and to get the MPS up and running on other platforms such as FreeBSD and Linux in very little time.

[rptb1]

OK, so kind of interesting, but what do we gain? It seems like a lot of work to switch.

[rptb1]

OK, so kind of interesting, but what do we gain?

@waywardmonkeys you could demonstrate one of the things you mentioned in #146 (comment) ?

CMake only seems to be able to make one target variety (build config) at a time by default.

[waywardmonkeys]

OK, so kind of interesting, but what do we gain?

@waywardmonkeys you could demonstrate one of the things you mentioned in #146 (comment) ?

Yes! I will do so (probably Monday).

CMake only seems to be able to make one target variety (build config) at a time by default.

You can use separate build directories, so this isn't an issue. You can do this either via:

mkdir /some/build/dir
cd /some/build/dir
cmake /path/to/code
cmake --build

or:

cmake /path/to/code -B /some/build/dir
cmake --build /some/build/dir

(You could just run make instead of cmake --build, but what I did will handle different generators and such, so it is easier for something like CI.)

[waywardmonkeys]

So, for clang-tidy for doing static analysis, on your cmake branch, you can do this from the base directory (assuming that like me, you have clang-tidy-15 on your PATH):

cmake code -B build-cmake-clang-tidy -DCMAKE_C_CLANG_TIDY=clang-tidy-15
cmake --build build-cmake-clang-tidy

And then you'll get a ton of output from clang-tidy including some interesting stuff which doesn't belong in this bug. :)

[rptb1]

You can use separate build directories, so this isn't an issue

At the moment, if you ./configure && make test you build and test several varieties (build configurations) and even run comparisons of one against another. The makefile generated by CMake seems only capable of building a single configuration. That means we might have to add extra scripts with loops in them, which themselves won't be Makefiles, and so won't do the dependency checking properly. Our current GNU Make system copes with all that correctly, even when building on several platforms in the same directory.

[rptb1]

extra scripts with loops in them

This sort of thing

cmake . -B hot -DCMAKE_BUILD_TYPE=Release && make -C hot test
cmake . -B cool -DCMAKE_BUILD_TYPE=Debug && make -C cool test

If you can combine -D with --build successfully I would like to see it. CMake's command line parsing is very weird and not Posix-like. I've not been able to combine --build with any other options except --verbose, hence the separate make invocation.

[rptb1]

cmake --build build-cmake-clang-tidy

Woah. Well, it certainly makes a lot of false but interesting claims 😉

[rptb1]

Hmm. https://stackoverflow.com/a/12024211 says:

it appears that CMake has no functionality to detect the target architecture whatsoever.

The horror.

[rptb1]

extra scripts with loops in them

So it seems CMake calls what we do with GNU Make a "multi target config". That is, we build multiple varieties of the same targets with different options. CMake's template using makefiles is only "single configuration". See https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations .

I'm not sure how important this is.