Meson: Going for 1.0

[jpakkane]

Every now and then people ask me when is Meson going to go 1.0. So maybe we should. I don't think anything would really change as we are fairly good at backwards compatibility, but it's a clear psychological signal.

This bug is mostly about discussion on what we should have for 1.0. I'd want at least these:

• improved generators, such as in #6526
• better Android support, being able to build (and deploy?) a complete mixed C/C++ and Java app

Kotlin support would be nice, I guess, but probably not a hard requirement.

[dcbaker]

I'd like to be able to cleanup/drop any deprecated things before 1.0, as that major version bump seems like a good time to do it.

[michaelbrockus]

I would love to add support for Kotlin JVM before 1.0. We should probably make a list of things to clear up for Meson build system's first major version bump.

[TheQwertiest]

One of the most important and direly needed features (IMO) is https://github.com/mesonbuild/meson/issues/5466 (+ default_library, cpp_std), because it's nearly impossible to use subprojects in it's current form without hacks. Currently one have to make an additional wrapper for dependency that filters out all conflicting options and builds dependency manually (e.g. subproject with custom_target that filters options and invokes meson of dependency instead of a plain meson subproject).

PS: Agreed with @dcbaker about interface cleanup.

[mensinda]

For 1.0, I would like to add cross-compilation support for CMake subprojects. This would make the CMake module basically feature-complete (except for bug fixes and corner cases we don't know and/or test yet).

[xclaesse]

The version is just a number...

That being said, I think 1.0 is not really about features being implemented, but rather how confident are we to be able to implement them later without breaking backward compatibility. 1.0 won't be the last release, we can still add features in 1.x, and if we start doing a list of stuff that everyone wants to have, we'll just never have 1.0 at all.

So I think the questions are:

• Do we have features that would be hard to implement without breaking compatibility?
• Do we actually want to break compatibility for 1.0 or is it already too late to break anything?
• Do we want to turn a few warnings into hard errors? (that has already been done in the past)
• Do we want to change the way we do releases? Like for example odd numbers being testing and even numbers stable.
• Do we have big architectural or organizational changes that would justify developing in a separate branch for a while and mark it 1.0 when completed?

I personally think that breaking compat is already too late and we could just release master today as 1.0 for fun. Like Torvalds likes to bump the Linux marjor version for no reason.

[nirbheek]

I think a major feature we need before 1.0 would be an easy-to-understand and consistent way to do breaking changes. Something that allows people to opt-in to old behaviour and explicitly disable warnings for those, which makes running with --fatal-meson-warnings actually feasible. Once this framework is in place, everything else follows.

[tp-m]

I think a major feature we need before 1.0 would be an easy-to-understand and consistent way to do breaking changes. Something that allows people to opt-in to old behaviour and explicitly disable warnings for those, which makes running with --fatal-warnings actually feasible. Once this framework is in place, everything else follows.

My thinking too.

[michaelbrockus]

😕 oh so I was not suppose to use --warnings-meson-fatal? I’m currently using it in Meson-UI, but I can totally see --fatal-warnings being more readable.

And as a follow up question why is --warnings-meson-fatal not documented?

[nirbheek]

😕 oh so I was not suppose to use --warnings-meson-fatal? I’m currently using it in Meson-UI, but I can totally see --fatal-warnings being more readable.

And as a follow up question why is --warnings-meson-fatal not documented?

It's --fatal-meson-warnings, I typoed. Corrected now. It is documented in the release notes and it shows up in the help output. Maybe we should document it elsewhere too.

[michaelbrockus]

Sorry about that just got up. Maybe it should also be documented in Meson built-in options page.

[germandiagogomez]

@nirbheek cmake has the policy system: https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html.

Maybe an approach is to have a file with policies that is not in the build files itself to not clutter build files with policies for breaking changes. So the policies can be set globally (per release in Meson itself) with its defaults and the user can have its own local policies.txt file to not break compatibility when upgrading.

This would allow to:

1. Add a new policy to meson (or breaking change or whatever the name is called) and not activate it by default.
2. Activate it when it is ready
3. If it breaks the user when upgrading Meson, then the user can override the breakage with its own file annotations.

File policies.txt:

polycy-1= value1
policy-2 = value2

Alternatively the policies could be a section in the native or cross file also. Not sure which one is better.

[scivision]

The recent CI enhancements make Meson feel more "1.0" ready to me.

• Subproject default override is important. Subprojects are a great strength of Meson except for this