Needing to tweak generated compile commands but not sure which ones

[metaleap]

Bit of a tricky one and somewhat lengthy, but only because I furnish below all the details I already uncovered, so we can avoid guesswork and have a clear detailed vantage =)

My project uses this system-wide-installed (at my end, at least) lib "WickedEngine" that's built with cmake, and their own example program (from which that lib's users usually start coding) also has a cmake setup — but I went straight to Meson for mine (of course =), and it's correct enough to build successfully BUT it generates a compile_commands.json that (either) causes (or won't prevent) the clangd language server in VSCode to generate in-editor errors that don't occur during the actual Meson-driven build (which does GCC or specifically ccache instead of Clang). Here's two examples:

(Again, the above codes build fine with Meson but clangd with the generated compile_commands.json "finds" errors that the final build doesn't.)

Well, the WickedEngine lib's example project's cmake setup doesn't by default generate any compile_commands.json, but VSCode+clangd-based users do so by adding -DCMAKE_EXPORT_COMPILE_COMMANDS=ON and told me that this fixed their false clangd error reports in VSCode, which went away by doing that.

So I went looking for the differences between my Meson-generated compile-commands.json and the cmake-generated one. I found plenty:

• cmake-generated compile command has -DNDEBUG -D_DEBUG flags that are missing in the Meson-generated ones
• cmake-generated has -isystem for WickedEngine's & SDL's include dirs whereas Meson-generated ones have -I/usr/bla/bla ones)
• Meson-generated further adds -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -fpch-preprocess -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -MD -MQ <bla/bla.o> -MF
• otherwise, apart from those differences, identical

My uneducated hunch is that I should have -isystem flags instead of -I ones for the system-wide-installed includes. That hunch comes from the first answer to my earlier question in #clangd (that was before I scrutinized all the differences listed above), screenshotted here:

So the questions:

• how would I nudge Meson to emit -isystem instead of -I flags
• do you build-hardened pros think another one of the above differences might the much likelier culprit to instead bring in to Meson-generated compile-commands.json (rather than -isystem vs. -I) — if so, which and how to nudge?

My current meson.build for reference:

project('mo', ['cpp', 'c'])

dep_wicked = dependency('WickedEngine', static: true)

lib_tmp = library('mo_hello', sources: ['mo_hello/mo_hello.cpp'])

executable(
    'mo.exec',
    link_with: [lib_tmp],
    dependencies: [dep_wicked],
    cpp_pch: 'pch/main.h',
    sources: ['main.cpp', 'mo_app/mo_app.cpp', 'mo_gfx/mo_gfx.cpp'],
)

Thanks in advance for your hunches on this one =)

[bonzini]

As a start, does it still fail if you add include_type: 'system' to the dependency call?

[metaleap]

As a start, does it still fail if you add include_type: 'system' to the dependency call?

Superb and many thanks, this got rid of the (more annoying) error in the 1st screenshot and still leaves the one in the 2nd to figure out.. =)

[eli-schwartz]

Note that -isystem is defined to modify the inner workings of #include_next and "fixincludes", it's not defined to have an effect on thirdparty header warnings. It's risky to misuse and abuse this, e.g. see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129, if your project fails to build entirely then the response from the compiler devs is just gonna be "don't use -isystem unless you are writing an alternative stdlib".

[bonzini]

Can you check by hand which of the differences (e.g. -DNDEBUG) are responsible for the error?

[metaleap]

Actually the error went fully away by removing my PCH (commenting out cpp_pch). Since my builds are done by gcc but clangd is the LSP, someone suspected that might be the cause, with clangd getting thrown off by gcc-produced precompileds. No idea whether this could be, myself.