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: #2085

[viric]

The SIMD module seems tuned to hand-written different simd code, while in some situations we simply want to provide the compiler with different instruction set / optimization flags for the platforms we are interested in.
That's meant to be done through static libraries and "c_flags" including the necessary -Osomething -mskylake.. etc. right?

[shardator]

We don't support per-file compiler flags by design.

I am forced to use Meson in my company, and this is just one more item on the long list of terrible design decisions that force some kind of hipster philosophy on people using a build system (like "it should not be Turing complete". Geez.)

It is EXTREMELY common that some files in a specific library need specific command line arguments, like this file uses AVX512, the other does not. This is unrelated to warnings, those can be handled with pragmas.

Please fix this. This is horrible.

[rhd]

The static library approach is a reasonable workaround to this per-file c/cpp args problem and it has worked well for me in the years since I opened this issue.

[shardator]

@rhd It works. However this feels like an unnecessary limitation for a build system. Like the other limitations they impose. Almost all of them (like no globbing for source files, etc.) And this can also become really cumbersome for third party libs, which are only Makefile based (I have this problem with a relatively small 3p library, but I can see myself tearing out all my hairs when trying to adopt a larger library with many files that need specialized command line flags.

[viric]

The point is to keep the recipes simple enough to read without much context.

[ajeb78]

There's more than just SIMD that you might want to specify particular compiler options per file though. Overall, my project cannot use -ffast-math, for example, because in some of the code dealing with cases like NaN and inf matters. But there are some highly processor-intesive parts of the code where -ffast-math is fine. Artificially segementing the entire codebase into libraries seems like a poor and over-rigid solution that could be better achieved simply by specifying -ffast-math for selected files. I'm sure there are other cases too.

[dogtopus]

Adding another reason to this list: GCC LTO is known to not mix very well with assembly code so some parts that contain inline assembly need to be compiled without LTO. This is also apparently what they recommends. No pragma can be used to turn LTO off and both inline assembly and LTO can be important to embedded projects so globally disable any of them may not be a real option.

[lbmeng]

In Makefile, the following pattern ($(CFLAGS_$(<:.c=.o))) is commonly used to pass the per-file compiler flags to C files.
Similar pattern exists for compiling assembly files too.

Please consider adding such a feature.

[jhgorse]

My use case is writing non-invasive test fixtures for legacy c code. It was done by remapping main() to something else. Obviously I need main() to eventually compile, so it cannot apply to the project. So I wrote the wrapper main in c++. Now apply the change to the c code and the c++ code goes through as usual.
add_project_arguments('-Dmain=original_main', language: 'c')

This is an ugly hack.

I will consider the static library or stick to CMake.

CMake supports this feature with good reason. The embedded community often does terrible terrible things because there is no other way. I have spent a good deal of time in that world and I feel there is no need to deprive them of Meson for reasons of purity or decisions by the gcc team outside of our control.

As a total swag at the design, this was a GPT hallucination when I was double checking the docs and tickets on this, but I kind of like it. In the <project>_sources = definition, add per file options using the files()

	files('../Src/main.c', c_args: '-Dmain=original_main')

When generating the build scripts, check if the file has extra flags and apply them additively. I suppose absolutely would be more generically useful with a variable to append if you like or overwrite as needed.

	files('../Src/main.c', c_args: '${c_args} -Dmain=original_main')

Cheers,
Joe