Meson: add_project_link_arguments adds arguments to native compiler

[ePirat]

I am using add_project_link_arguments to set linker arguments but those end up applied to the native compiler not the cross-compiler.

This is IMO a bit unexpected but I guess changing this is not really possible without breaking things.
So maybe a native kwarg can be added, so that it can be chosen to which compiler the flags will be added.

[jpakkane]

I guess the rationale for that has been that cross arguments are heavily platform and toolchain dependent and thus make more sense to put in the cross file instead. Otherwise you get a big if/else thingy if you need to support many different platforms.

That being said if there is a good use case for adding the native keyword we could do that, but we should probably then add it to all add_XXX_args type functions.

[tp-m]

How does add_project_arguments() behave then?

Many projects will use something like

if cc.has_link_arguments(xyz)
  add_project_link_arguments(xyz, language: 'c')
endif

so to me this is not just unexpected, but seems more like a bug (unless it behaves the same for arguments, then I just never knew and it's all weird but at least consistent).

[Ericson2314]

Agreed this is a bug. IMO these sorts of issues are too likely because while native : true isn't the default in meson's interface (good!), it is the default in meson's implementation (bad!). Beyond my philosophical disagreement with building for native being the default (code gen tools are not the common case) the mismatch creates tons of conditional code where their need not be.

I'd love to see *cross* stuff internally removed and *_for_build stuff put in it's place, as Autoconf does it. This keeps the host platform the default for whether or not one is cross compiling and makes building for the build platform consistently the special case across the board.

[jpakkane]

The main reason this does not work is that add_XXX_arguments predates cross compilation support and we just forgot to fix that when cross support was added.

[xclaesse]

Similarly -Dc_args is for native compiler only. I don't think we can pass args to cross compiler outside of cross file. In that case I think it's fine, even if a bit unexpected.

But for add_xxx_arguments I was definitely assuming they would go to cross compiler. I didn't notice it before, but that's a problem for glib at least.

I think we have to add 'native' kwarg and default to false.

[jpakkane]

It should default to the same as every other function that has it, that is, to host if native compiling and cross build if cross compiling. It's a breaking change but one we can probably get away with.

[nirbheek]

It should default to the same as every other function that has it, that is, to host if native compiling and cross build if cross compiling. It's a breaking change but one we can probably get away with.

After reading the arguments on this bug, I've changed my mind and we can probably do this.

[xclaesse]

Reading the code, as far as I understand add_project_arguments() and friends apply to both native and cross compilers. If we are going to add native kwarg, we better deprecate them and add as method on the compiler object, no? That would solve the backward compat question, we can keep deprecated functions to apply on both cross and native.

[ePirat]

It does not sound like a good idea to me to add methods to set args to the compiler objects, this would make setting arguments needlessly complex.

For example instead of:

add_project_arguments('-mmacosx-version-min=10.10',
        language: ['c', 'cpp', 'objc'])

I would have to do something like:

cc = meson.get_compiler('c')
cpp = meson.get_compiler('cpp')
objcc = meson.get_compiler('objc')

cc.add_argument('-mmacosx-version-min=10.10')
cpp.add_argument('-mmacosx-version-min=10.10')
objcc.add_argument('-mmacosx-version-min=10.10')

[ePirat]

And it would make the fact that currently the arguments do not affect all compiler checks even more confusing.