Build output parser not picking up certain include locations

[gvl2023]

Cmake-generated C++ makefile project on Linux, using vanilla CDT/2022-12 C++ Eclipse package. I'm facing an issue where some -I directories (as absolute paths) are missed by the build output parser. Most are fine however. I checked on regex101 and the default expression matches the troubled compiler invocation lines. I've seen an occasional success w/no change in the compile command. Any ideas?

[jonahgraham]

Can you share the output that is tempermental? Maybe someone can spot something unusual about it. Are you using GCC, or some other compiler?

One quick thought is if there is some unexpected buffering happening.

[gvl2023]

This is GCC. I think this has to do with my setup. This is a cmake-unity build and cmake-generated unity files are placed outside of the source tree, and that's what gets compiled. Because of it I don't think I can store discovered entries on the file or even folder level as keeping them with the unity resources or their parents in a separate sub-tree won't help the indexer when it goes through the actual sources, so I'm keeping discovered entries at the project level. I realize this is technically incorrect as this is a rather extensive codebase with many projects that have different switches/include paths but this is the best I can do at the moment. My expectation was that once the build completes the set of discovered include directories and -D macros kept at the project level is a union of all those detected by the build output parser, even when individual compiler invocations may have different -I and -D values. What seem to be happening is that earlier discovered values are discarded and replaced by what's found by the last command that ran, or something to that effect. Is that a bug or by design?

Another thought, I'm running a parallel build, so it may be a concurrency issue. I will try a -j1 build to rule it out.

[jonahgraham]

What seem to be happening is that earlier discovered values are discarded and replaced by what's found by the last command that ran, or something to that effect. Is that a bug or by design?

That is a good question. To be able to better answer this I need to know which type of project you are using. e.g. are you doing "Makefile project with existing code", "Empty or Existing CMake Project" or something else?

Another thought, I'm running a parallel build, so it may be a concurrency issue. I will try a -j1 build to rule it out.

Certainly interested about this. Sometimes a non -j1 build interleaves the output of multiple gccs in such a way that the parsing fails.

[gvl2023]

This project was created as "New C++ Project -> Makefile project -> Empty project -> Linux GCC", which I think is more or less the same as the "Makefile project with existing code".

My linear build is still going, will post my findings later.

On a related subject, the currently available Eclipse cmake integrations I found (Eclipse's own and Cmake4Ecilpse) don't quite work with cmake unity builds due to the fact they feed the indexer from compile_commands.json. Unity build support may be one reason to switch the Eclipse cmake plugin to using cmake file-api if the responses it produces help to track down the actual fused source files, but I haven't spent any time to try to understand if they actually do (re: Bugzilla 545905).

[jonahgraham]

This project was created as "New C++ Project -> Makefile project -> Empty project -> Linux GCC", which I think is more or less the same as the "Makefile project with existing code".

Thanks.

My linear build is still going, will post my findings later.

Great.

On a related subject, [...]

That may be the right way forward, but it is under invested as evidenced by that bugzilla. The good news is that as some of the embedded vendors are now transitioning to using cmake more that may lead to some further investment in that area. For now there is an initiative to add clangd as the indexer for CDT using LSP.

Reading through this clangd issue report seems that clangd is going to have problems with unity build too. AFAICT clangd doesn't have support for cmake-file-api either.

[gvl2023]

It does feel cmake has a lot of traction in the industry, so perhaps a better cmake integration can help boost interest in Eclipse/CDT for native development as it did for VS Code and VS proper.

As for the actual problem on hand, my linear build just finished after 4 hours and 15 minutes, and the final set of discovered entries correlates well with the last compiler invocation, so it does appear that there is currently no provision in place to aggregate all the discovered items and simply the last compile line wins. I suspect this is by design as the "per project" setting assumes all settings are the same for all files. This is unfortunate as this was my last hope to get our build infrastructure integrated with Eclipse CDT, in a non-crippled way anyway. One way out would be to not use unity builds but this is not going to happen (don't ask me why).

[gvl2023]

Well, I may have been overthinking it. I made the output parser to store entries at the folder level and it actually worked - the indexer was able to figure out that source files were included from unity, apply the discovered context and now everything works mostly as expected.