Meson 0.50 Build System Brings PGI Compiler Support, Various Fortran Improvements & CUDA

[phoronix]

Phoronix: Meson 0.50 Build System Brings PGI Compiler Support, Various Fortran Improvements & CUDA

Meson 0.50 is now available as the latest feature update to this increasingly used cross-platform build system that is powering the likes of many GNOME projects, many X.Org/FreeDesktop.org low-level software components, and other software that when paired with Ninja is known for its lightning fast build times and better cross-OS support compared to traditional alternatives...

http://www.phoronix.com/scan.php?page=news_item&px=Meson-0.50-Build-System

[usta]

micheal phoronix : It looks like there is a typo in article : also prevents various improvements ---> i believe it must be not prevents but presents

[Weasel]

ninja is good, but meson is hot garbage especially since it's written in python and actually requires pretty recent python. You can use ninja with cmake as well, even though all build systems suck, but meson tops the cake due to its implementation and dependencies.

[crymsonpheonix]

ninja is good, but meson is hot garbage especially since it's written in python and actually requires pretty recent python. You can use ninja with cmake as well, even though all build systems suck, but meson tops the cake due to its implementation and dependencies.

Dude, you have got to work on your trolling, the implementation bit is an opinion, it's a good thing to troll over, the dependencies thing? meson only requires ninja and python 3.5 (from 2015). I'll give you a B for effort, but a C- for execution.

[discordian]

Dude, you have got to work on your trolling, the implementation bit is an opinion, it's a good thing to troll over, the dependencies thing? meson only requires ninja and python 3.5 (from 2015). I'll give you a B for effort, but a C- for execution.

Meson requires wrapper script for anything outside of the base functionality (the software the meson authors care about), software wanting to eg. put setuid on an executable will typically come with a shell- or python script tacked on, and in my experience those break down as soon as you crossbuild or use a sysroot.
Worst-of-all: try to target microprocessors.

Meson needs all those bandaids which are typically horrible per-project-hacks, which already are solved with flexible solutions - even with freaking autotools. So yeah, Meson is nice if its used for the few projects its build for. The dependencies are the bandaids necessary, and the dependencies of those. With CMake bandaids are atleast possible as CMake scripts, and ideally already available as module.

[dcbaker]

Meson requires wrapper script for anything outside of the base functionality (the software the meson authors care about), software wanting to eg. put setuid on an executable will typically come with a shell- or python script tacked on, and in my experience those break down as soon as you crossbuild or use a sysroot.
Worst-of-all: try to target microprocessors.

Actually, we've supported setuid/setgid (and actually control over all of the mode flags) at install time since 0.47.

We have support for at least one micro processor. We'd like to add support for more, but we need to people to show up and write and maintain that code. 0.50 has a ton of fortran work in it, because someone who understands fortran showed up and wrote a ton of code (which the rest of us really appreciate because we're not fortran experts).

tl;dr If there is a feature that more than one project needs, suggest it.

[discordian]

Actually, we've supported setuid/setgid (and actually control over all of the mode flags) at install time since 0.47.

In 0.47, which ships in how many distros to this day?
The point is that packages have to put on bandaids for those older versions.
There aint a way to extend meson, its upstream or bust.

We have support for at least one micro processor. We'd like to add support for more, but we need to people to show up and write and maintain that code. 0.50 has a ton of fortran work in it, because someone who understands fortran showed up and wrote a ton of code (which the rest of us really appreciate because we're not fortran experts).

Yeah, the Jury is also still out on whether you will manage to support C++20 Modules.

Around 2 years ago I had a through look at Meson & co, problem was/is to support a range of STM32 Microprocessors. you will find some examples if you google for stm32 + meson to get an idea whats necessary (ex.: https://hwengineer.github.io/discovery_enhanced2/, note this is one SOC family of many).
The point is that you have to copy and adapt meson.build templates for every project, while with CMake you write one library project which contains the sourcecode, and a .cmake script that can synthesize those settings for multiple SOC and compilers. you then just link this project, and maybe call a few functions to override eg. the default linkerscript.
With meson such an extension is "upstream or bust", which is an insane model for the broad C/C++ Community.
So I dont know what you mean with "we support at least one microprocessor", your DSL certainly aint fit for using something like "Board Support Packages" defining startup-code and clock-parameters, and fiddling with compiler settings per-project does not count for me.

tl;dr If there is a feature that more than one project needs, suggest it.

You know, communicating back the compiler-specifics (default macros+include paths) would be nice, so an IDE can correctly resolve headers and symbols... for those fools who cross-compile most of the time.

[andreano]

I don't care if Meson can't do this, or can't do that, when some rather common things are plain impossible in CMake. Like using pkg-config together with add_externalproject. Meson submodules just do this!

[discordian]

I don't care if Meson can't do this, or can't do that, when some rather common things are plain impossible in CMake. Like using pkg-config together with add_externalproject. Meson submodules just do this!

That's another really poor solution, if you link to 2 subprojects both using a common submodule how do you make sure it's the same version?
That's out of scope for a buildsystem, you would just use find_package everywhere and a dependency management tool like Conan will pick (on your request) fitting local version, cached precompiled ones or build from scratch.

Editing subprojects for the build doesnt scale, versioning info does not belong there. what would belong there are usage macros like the example with microprocessor libraries or as another example generating code with generators (like protobuffers) otherwise you end up with this usage code spreading everywhere (the meson approach) and being yet another nightmare if there are differences between version.

[andreano]

if you link to 2 subprojects both using a common submodule how do you make sure it's the same version?

I don't know in the case of Meson, but I don't think it is forking itself when descending into a subproject, so it should be in a position to at least detect a version conflict. The solution in Rust/Cargo is to ship a cargo.lock file in the top-level project that "locks" everyone's versions to the ones that worked for you (or if you don't have such a file, it will be generated, detecting version conflicts along the way). Just saying it can be in scope for a buildsystem, and it's not unsolvable like with recursive buildsystems.