Meson: Add gcc flag to a specific file

[rhd]

Is it possible to add a flag to a specific file? I have some generated code that's freaking the compiler out and I don't feel like mucking with the generator.

This is how you would do it in cmake.

SET_SOURCE_FILE_PROPERTIES(fileName.cpp COMPILE_FLAGS -fno-var-tracking) 

[nirbheek]

Meson does not have a way to do this, but if you want to disable a specific warning, there's GCC pragmas for that which you can put in your generated source.

Alternatively, you can generate a static library with the generated code, specify the compiler flags there, and link it to the rest of your targets.

[QuLogic]

This is something I initially thought declare_dependency would have handled, but alas I forgot that compile_args bubbles up from there.

[msink]

Maybe add kwargs like cpp_args to files() ?

[jpakkane]

We don't support per-file compiler flags by design. It interacts very poorly with other parts, especially precompiled headers. The real solution is to fix the generator to not produce garbage. Obviously this is often not possible so the solution to that is, as mentioned above, build a static library with the specific compiler args. This has the added benefit that it makes this workaround explicit and visible rather than hiding things in random locations.

[msink]

Yes, static library.

Or, maybe extend syntax like this:

foo = executable('foo',
  sources: [
    ...
    generated_code,
  ],
  cpp_args: [..., '-fno-var-tracking' for generated_code],
  ...
)

[rhd]

Thanks guys - building as a static lib was the easiest way to workaround this. And since nothing is easy, clang doesn't support -fno-var-tracking-assignments.

[lieff]

@jasperla But it's needed by gcc design. We can't just enable -msse4 for all project, and we can't compile sse4 intrinsics without it. There ton of more examples where different compiler flags absolutely needed, but this is _very_ popular one. Projects like x264, ffmpeg, libvpx etc rely on this and making new static lib for every use of different options is _very_ bad solution.

[TheQwertiest]

I support @lieff on this one: we have multiple files that have different -msseX/-mno-sseX flags that are part of a single project, moving each file into a separate library sounds like a dirty hack and not a proper solution :\

[jpakkane]

For that we have the SIMD module. It aims to provide a higher level API for the same thing. If it is missing features, please let us know so we can add them.

[TheQwertiest]

Thanks! That looks exactly what we need! (experimental status make me a bit wary though)

[lieff]

Cool :) Thanks, I think this covers 90% of all cases.

[jpakkane]

Things move out of experimental once people use them and let us know that they are working and have good UX. :)

[mstoeckl]

There's a special case which the SIMD module doesn't perfectly handle, and requires falling back to static libraries: when a SIMD function implementation requires a combination of instruction set flags that don't imply each other, like -mavx -mlzcnt or -mavx -mbmi2. Because AVX512 is broken up into many sub-instruction sets, it may produce similar problems.

[TheQwertiest]

There are also -maes, -msha and probably many-many more non-inclusive flags (e.g. MIPS specific SIMD/intristics flags).
SIMD module approach would require to research and implement the logic for all of the flags in https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options

[TheQwertiest]

Corresponding issue for AVX512 support: https://github.com/mesonbuild/meson/issues/2085