Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] cmake support how to integrate the compile_commands.json parser into CDT

Op 17/06/2020 om 22:00 schreef 15 knots:
Am Mi., 17. Juni 2020 um 21:09 Uhr schrieb Mark B <marco.stornelli@xxxxxxxxx>:
Il mer 17 giu 2020, 21:02 15 knots <fifteenknots505@xxxxxxxxx> ha scritto:
Hi Alexander,

Am Mi., 17. Juni 2020 um 09:31 Uhr schrieb Alexander Fedorov
> Well, currently all these parts, such as the "server" and "front-end", are managed from the IDE.
> For example if user adds the source file - it needs to be added to json as well, and we need to guess the commands for this new unit, and for this we need to know how the surrounding units are configured.

Just *creating* a source file does not *add* it to the files that get
compiled. Cmake users must modify the CMakeLists.txt file to have the
new file compiled:

Unless you use a file glob option *.cpp in this case you don't need to modify it even if it's a discouraged approach actually.
Sure that will work. But then users will have to manually launch cmake every time they add or delete a source file. [1].
Unless CDT modifies the user's CMakeLists.txt and silently adds a CONFIGURE_DEPENDS. Well, the CONFIGURE_DEPENDS will give them a build-performance degradation that might be acceptable for hello-worlds. But not for projects with 1k or more source files.

I do not really understand this discussion.

Gnu managed build makes (if necessary based on listeners) a makefile at build start based on the project referenced files. As sloeber uses name providers all files need to be found and added to the makefile (collection of makefiles that is)

Sloeber uses the same approach (based on indexer finished listener) to process the .ino files before the build starts.

I don't see how you can avoid something like this unless eclipse CDT is reduced to a notepad++ (which is what platformio is doing and what a eclipse Arduino CLI based implementation would do)

Gnu managed build takes by default the project level compilation commands and options but lets you override them (in the gui) on a folder or file level basis. I think of it as: the server is maintaining the data and the gui uses the server to set the data (MVC approach).

Can someone explain why the Cmake or LSP would deviate from this approach so I can at least understand what this discussion is about?

Thanks Jantje

cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top