CMake Compilation DB remains empty when cross compiling using a toolchain file

[bw35]

Describe the bug
When using a cmake toolchain file for cross compilation, the CMake Compilation DB remains empty. The compiler defined include paths, compiler set #defines and defines set in CMakeLists.txt are not propagated to the Eclipse indexer.

To Reproduce
Steps to reproduce the behavior:

1. Install Eclipse CDT 2022-12 and the cmak4eclipse 4.0.0 on Windows
2. Create a new cmake4eclipse project as described in the user manual
3. In "Cmake4eclipse Build / CMake Options", add the CMAKE_TOOLCHAIN_FILE cache variable and assign the FILEPATH to the toolchain file to it.
4. Build the project
5. Examine "C/C++ General / Preprocessor Include Paths / Entries / CMake Compilation DB". No entries have been added.

A small project demonstrating the problem is attached. It contains two build configurations:

• "Debug" using the native compiler C:\msys64\mingw64\bin\cc.exe. This creates include path entries in the CMake Compilation DB.
• "Cross compile" using arm-none-eabi-gcc.cmake toolchain file, not propagating the CMake Compilation DB

Expected behavior
CMake Compilation DB propagated not empty when cross compiling

Further observations

• compile-commands.json is properly generated in both cases.
• "Detecting compiler built-ins for project 'test'" configuration step is not run when cross compiling

Useful Information

• cmake4eclipse version: 4.0.0
• Which OS do you use: WIndows 10
• Cmake version: 3.25.1
• Eclipse CDT: 2022-12
• Native Compiler: MinGW-w64 gcc 12.2.0
• Cross Compiler: arm-none-eabi-gcc 12.2.Rel1

test.zip

[15knots]

The "C/C++ General / Preprocessor Include Paths / Entries / CMake Compilation DB" tab is not always immediately updated by CDT. To see the exact settings,

• open one of the source files in the C-Editor,
• activate the editor, then
• select menu Project | C/C++ Index | Create Parser Log File.

You can find the exact include search path in the log file.
If the search path shows as empty, it might be the case that the compiler is not recognized.
If so, you can find more information if you enable the Info-level in the Problems view.
A message like "no parser for command ..."will clearly indicate the compiler is not recognized.

See also #117, #122 and #124

[bw35]

Attached you find the parser logs for both the native and cross compilation case. The latter shows no trace of any compiler built in include path or define. There's no hint why it fails. BTW cross build works fine, i.e. the cross compiler is found along the path and is working ok.

parser-native-gcc.log
parser-cross-gcc.log

Following the discussion of the issues you linked, I guess its a problem with the name of the compiler executable. Here's the relevant portion from compile-commands.json:

"command": "C:\\PROGRA~2\\ARMGNU~1\\12DBAB~1.2RE\\bin\\AR19DD~1.EXE -DMYDEF=1 -Dtest, - ..."

CMake is using the 8.3 file name for the compiler executable. Since short file names are more or less random, no regex will help here, hence the option parser can't recognize it as a gcc variant.

See also #31, which narrows the problem down CMake using 8.3 filenames if the path to compiler paths contains spaces. Thanks @nolange, you made my day :-)

Solution
Reinstall the compiler to a path w/o spaces. I wonder how many people will face this problem, since the default suggested by the toolchain installer contains spaces.

Suggestions for improvement
A possible enhancement would be a visible kind of warning, that the compiler type can't be detected by the option parser and maybe a hint, that using toolchain installation paths containing spaces will break things.
As possible workaround is to implement some heuristic to guess / probe the compiler type. The result may be cached to avoid performance cost. To fix the root cause, CMake should stop using short file names.

[15knots]

CMake is using the 8.3 file name for the compiler executable. Since short file names are more or less random, no regex will help here, hence the option parser can't recognize it as a gcc variant.

The fix for #31 has already been ported to CDT. The code is in expandShortFileName(). No idea, why the fix does not work. I could never really test it since I am on Linux. Note that the method comment mentions a bug in cmake that is still unresolved.

Suggestions for improvement
A possible enhancement would be a visible kind of warning, that the compiler type can't be detected by the option parser and maybe a hint, that using toolchain installation paths containing spaces will break things.

This would require changes in CDT. You may want to file a bug there.

As possible workaround is to implement some heuristic to guess / probe the compiler type.

Guessing is already implemented. Probing (by running the compiler with options that make it spit out its version info) would be really hard: Options differ per compiler; version output differs, too.

[bw35]

The fix for #31 has already been ported to CDT. The code is in expandShortFileName(). No idea, why the fix does not work. I could never really test it since I am on Linux. Note that the method comment mentions a bug in cmake that is still unresolved.

Thanks for the pointer, I'll take a look at it when I find the time.