WIP: Meson build system

[bog-dan-ro]

Meson it a cross platform modern build system, it's used by quite a few projects to migrate from autotools (most of xorg projects, gnom(including GTK [mm], postrges, etc.).

Closed: #7

[stlintel]

Hi

How about writing a manual what this PR does and why ?
What are the pros/cons of new build system ? How it should be used ? Is it cross platform ?
Linux only ? Windows ? Cygwin ?
How it co-exists with current way of building Bochs and configure scripts ?

Thanks
Stanislav

[stlintel]

I suggest to split new build system from related changes like [BX_USE_RAW_SERIAL]

[bog-dan-ro]

The patch is work in progress, I tested it only on Linux and only with the default options.
IMHO we should create a new branch (e.g. meson) and push it there so more people will be able to contribute without waiting for this patch to be merged.

Currently it can coexist with autotools, but I expect that in the future autotools will be retired.

If you think that cmake is more suitable for you I can add cmake instead.

Btw, are all these options really necessary? E.g the xxx_smf? I spent more time on these options than I spent for the rest of the stuff 😒.

Also, is it possible bump the requirements to at least C++11?

[AndersonTorres]

What are the pros/cons of new build system ?

Well, I am involved in a similar project of converting autotools to meson in Nix:

https://github.com/AndersonTorres/rfcs/blob/meson-builds-nix/rfcs/0132-meson-builds-nix.md

Summarizing:

• user-friendly Python-esque DSL
• multiplatform support
  • among operating systems: Linux, *BSD, Apple MacOS, Microsoft Windows NT
  • among programming environments: GCC, Clang, Xcode, Visual Studio etc.
  • among programming languages: C, C++, D, Fortran, Java, Rust etc.
• supports command customization
• cross compilation
• many useful modules included (pkg-config, filesystem inspection, internationalization etc.)
• out-of-source build support
  • indeed, meson does not support inside-source build
• Comprehensive documentation
  • including tutorials, reference manuals and real world projects using it

How it should be used?

In tandem with Ninja (all platforms) or generating project files for Xcode and VSC++.

It can be easy as

$> meson setup build-directory
$> meson compile -C build-directory

How it co-exists with current way of building Bochs and configure scripts ?

It can coexist without interferences. Maybe for projects that download things while building it can be a bit restrictive because it requires all artifacts to be inside subprojects directory.

On the other hand, it can easily substitute autotools.

[Vort]

If you think that cmake is more suitable for you I can add cmake instead.

I think Autotools is old and inconvenient enough to be replaced by something.
As for which replacement is better - it is hard to say.
I only tried to use CMake and I think it is quite good.
Never heard about Meson.

Probably it make sense to get comparison from person who knows all 3 build systems.

It can coexist without interferences.

I doubt coexisting is a good choice.
Right now MSVC projects and Autotools needs to be maintained separately.
Add Meson to it - and there will be 3 places instead of 2 where changes should be synchronously made.

[AndersonTorres]

It can coexist without interferences.

I doubt coexisting is a good choice.

I am not arguing for coexistence.
I am pointing out that there is nothing in Meson that requires the removal of a previous Autotools fileset.

Right now MSVC projects and Autotools needs to be maintained separately. Add Meson to it - and there will be 3 places instead of 2 where changes should be synchronously made.

With some luck, Meson can generate the MSVC fileset. It reduces 2 to 1.

[eli-schwartz]

I doubt coexisting is a good choice.
Right now MSVC projects and Autotools needs to be maintained separately.
Add Meson to it - and there will be 3 places instead of 2 where changes should be synchronously made.

Well...

I am not arguing for coexistence.
I am pointing out that there is nothing in Meson that requires the removal of a previous Autotools fileset.

Absolutely.

The thing about coexistence is that when you have an existing build system it is usually considered unwise to remove it until you know the replacement is complete,

It is somewhat common for projects migrating between build systems to implement a new one, mark the old one as deprecated, and prepare to drop the old one after a couple months, or after one release, or something like that. The idea is that this gives people a chance to try the new one and verify that it handles everything needed, before removing the setup that people were depending on.

While there is some reason for projects to want multiple build systems, this is typically limited to the libraries use case, and only to facilitate embedding, not as the primary build system. This isn't really something that autotools or Visual Studio support anyway.

[Vort]

unwise to remove it until you know the replacement is complete

I was talking about final goal (stable state), not about how it will be achieved (transition state).