| Re: [cdt-dev] cmake support how to integrate the compile_commands.json parser into CDT |
Jonah
Thanks for the explanation. It is always way more complicated than I think :-)
Jantje
Jantje,
We are trying to support CMake users. This has two parts:
1- Starting from a cmake file have the CDT indexer work and all related machinery work. Martin has been providing his expertise and code to the CDT project and has https://marketplace.eclipse.org/content/cmake4eclipse which does this already.2- Having a UI to edit the cmake file (this is not in scope of current discussions - but Martin has https://marketplace.eclipse.org/content/cmake-editor#group-screenshots which provides an editor for cmake files)
This conversation is not about a replacement for managed build.
Summarized in a different way:- Sloeber / managed make has a GUI that you can enter compiler options and that is passed to the compiler- CMake support has a black box that we have to extract compiler options from to drive the UI
I hope that provides some context.Jonah
On Wed, 17 Jun 2020 at 16:41, Jan Baeyens <jan@xxxxxxxxxx> wrote:
_______________________________________________
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
<alexander.fedorov@xxxxxxxxxx>:
>
> 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 aCONFIGURE_DEPENDS. Well, theCONFIGURE_DEPENDSwill 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 cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev