Meson: RFC: Proposal to rework c_args and friends

[Akaricchi]

The behavior of *_args is currently inconsistent between native and cross builds. In native builds, it affects both the intermediate "native" tools that we want to run at build time, and the actual end-goal build targets. In a cross build, the later become "cross" targets and thus are not affected by *_args (except those added in a cross file).

There are a couple of problems with this:

• It's not obvious what is going on and why. Issues have been opened because of this confusion in the past. See #4767, #4331.
• There is no universal way to configure extra arguments of build targets, short of introducing a custom option.
• There isn't even a way to globally add custom cross arguments (again, without modifying the build definitions or the cross file).
• Using the same flags for intermediate build-tools as for the actual targets may not be what you want, even if not cross-compiling.

What I'm suggesting is the same concept outlined in #4933: think in terms of build and host, not native and cross. So instead of c_args etc., we could have something like this:

• build_<lang>_args, build_<lang>_link_args: used for "native" targets only (native is explicitly true).
• host_<lang>_args, host_<lang>_link_args: used for other targets (native is either false or unspecified).
• <lang>_args set in the cross files may map to host_<lang>_args.
• In the future, maybe also deprecate the native kwarg and replace it with machine, accepting one of the global machine objects.

[jpakkane]

Putting cross arguments in an option called cross_LANG_args so they are visible and editable was the original design plan. I'm even fairly sure I implemented it that way but either that is not the case or that was accidentally lost in a refactoring.

[Akaricchi]

Putting cross arguments in an option called cross_LANG_args so they are visible and editable was the original design plan. I'm even fairly sure I implemented it that way but either that is not the case or that was accidentally lost in a refactoring.

I have seen this mentioned a few times, but I'm pretty sure these cross_* options never existed. I'm doing cross builds on a regular basis and I've never seen them show up in the configure output. Even if they did exist, which would've been a massive improvement, I still believe that it's not an ideal design. What you really want is an option that means "compile my project with these args"; whether it's a cross build or not is not a useful distinction here.

[dcbaker]

I wasn't originally convinced by the build/host/target vs native/cross thing, but I've become convinced that thinking in build/host/target terms is correct. The fact is that generally people don't care too much about the build flags, but they do care a lot about changing the host flags, whether that's in a cross compile or not.

[Ericson2314]

https://github.com/mesonbuild/meson/pull/5110 reserved cross_, but per this proposal we might want to reserve host_ and build_ too.

[Ericson2314]

https://github.com/mesonbuild/meson/pull/4931 made a cross_ builtin option as a stop-gap.

[Ericson2314]

I implemented this in https://github.com/mesonbuild/meson/pull/5263, replacing the cross_ stuff from https://github.com/mesonbuild/meson/pull/4931 (So definitely let me know what you think, @dcbaker!). We should make a decision on which approach for 0.51.

[Ericson2314]

Fingers crossed, but I think https://github.com/mesonbuild/meson/pull/5263 should pass tests on Windows now. As I say in https://github.com/mesonbuild/meson/pull/5263#issuecomment-487453246, hopefully this means it's finally worth discussing this and related issues about native-cross vs build-host so we can reach a common understanding.

edit it does.

[Ericson2314]

https://gitlab.freedesktop.org/wayland/weston/merge_requests/157/diffs Here is an example of code in the wild using is_cross_build() to implement something that should be unconditional. The ideal incantation is:

prog_scanner = find_program(
  dep_scanner.get_pkgconfig_variable('wayland_scanner', native: true))

i.e. always lookup on the build machine package config path.

This isn't options, but the idea of native: true is what's trying to be emulated here. native: true is good because it works in native and cross and builds alike, because it just means "build machine". cross: true isn't so useful because it means "skip" on native and "host machine" on cross, rather than "host machine" everywhere. cross_* in options has the exact same problem.

[marc-h38]

The behavior of *_args is currently inconsistent between native and cross builds

I just shared some prototype test code in #6362 if you're interested.