Make native-file and cross-file behaviour consistent

[JPTIZ]

If you define a [properties] section defining e.g. c_args in a native-file.txt and pass it to meson with --native-file, the c_args is ignored. But when passed with --cross-file (even if it is not a cross-compilation), it works as expected (i.e. the c_args are passed to the compiler).

I've made an MRE for reproducibility purposes (and to simplify the explanation): https://github.com/JPTIZ/meson-native-file-mre.

How to reproduce

1. Have a native-file.txt specifying compilers and some c_args (e.g. -DUSING_NATIVE_FILE and -DSOME_VALUE=1):

   [binaries]
   cc = 'gcc'
   cpp = 'clang++'
   
   [properties]
   c_args = ['-DUSING_NATIVE_FILE', '-DSOME_VALUE=1']
   cpp_args = ['-DUSING_NATIVE_FILE', '-DSOME_VALUE=1']

2. Have a C source file using those definitions;

3. Run:

   $ meson build --native-file native-file.txt
   $ ninja -C build
   $ ./build/test_program
   SOME_VALUE: 0

4. As it can be seen, no -D was sent to the compiler (altough it does select gcc and clang++).
5. Then:

   $ rm -rf build
   $ meson build --cross-file native-file.txt
   $ ninja -C build

6. Now it sends both -D:

   $ ./build/test_program
   This was compiled with native-file.
   SOME_VALUE: 1

What is expected

At least for me, I would be expected for them both to work the same way (i.e. both consider c_args and send to the compiler). Since both files-definitions are pretty close to each other (to not say "the same"), a different behaviour seems misleading.

Some reasoning

It would be pretty useful for my current workflow, where I have to deal with many specific warnings one by one, so I define tons of -Wno-* and then re-enable them back one at a time (while keeping regular -Wall -Wextra). But, in Windows, having pretty long procedures (in a batchscript) or environment-variables may lead to errors. I could define them in meson.build, but that would mean messing with the build system to add flags that are temporary.

[dcbaker]

I think I have a slight preference to just deprecated putting compiler/linker arguments in properties and move them to a new section ([toolchain] maybe?) but we absolutely should support this from both the cross and native file either way.

[JPTIZ]

I think I have a slight preference to just deprecated putting compiler/linker arguments in properties and move them to a new section ([toolchain] maybe?) but we absolutely should support this from both the cross and native file either way.

Indeed a different section could make more sense, even because compile-flags may differ from a toolchain to another. Something like [toolchain.gcc], maybe?.

[xclaesse]

Indeed a different section could make more sense, even because compile-flags may differ from a toolchain to another. Something like [toolchain.gcc], maybe?.

I'm not sure that's necessary, I would rather use config file composition, like --native-file common.txt --native-file gcc-toolchain.txt if you want toolchain specific settings. You can only use one toolchain at a time, afaik.

I think I have a slight preference to just deprecated putting compiler/linker arguments in properties and move them to a new section ([toolchain] maybe?) but we absolutely should support this from both the cross and native file either way.

I have that feeling too, [properties] is a bit a bag for everything. Maybe that section should only contain project specific values that are accessed by the project using get_cross_property() and get_external_property(), and for overrides of some compiler checks. Not sure it's even documented, but has_function() can be override by a property in cross file, I think that's something from autotools.

Thinking about it, setting c_args in [properties] could be simply deprecated in favor of setting c_args in the future [options] section, would would be a nice way of unifying how to set those cflags.

[dcbaker]

I agree, I think reducing properties to a "random bag of variables for get_external_property" is the right direction, and everything else should be moved out to other sections. setting via the options section makes sense.

[tkenvin]

I think that this can now be closed for two reasons:

• according to the documentation, as of 0.56.0, <lang>_args in the properties section is deprecated https://mesonbuild.com/Machine-files.html#properties
• the issue seems to have been fixed! (in 0.56.0.rc1)

Please let me know if I'm wrong as I would be keen to gain a better understanding.

[xclaesse]

Right, closing now, thanks.