Re: [cdt-dev] Are managed projects a requirement/recommendation or the n

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

I think it is even more confusing. There are two non-MBS Make implementations. One is the pre cdt 3.0 one, and one is the core build one.

The pre 3.0 one does not have a project wizard anymore AFAIK. But the other one is in the new C/C++ Wizard, labelled experimental.

Finally, many of the unit tests in CDT create old versions of projects and rely on being upgraded as part of the rest itself. Therefore using those tests as examples can be misleading. 

HTH 

Jonah 

On Wed., Dec. 9, 2020, 19:40 Marc-Andre Laperle, <malaperle@xxxxxxxxx> wrote:

I would add here to the confusion that non generated Makefile projects (external builder) sit on top of the MBS code, which was a motivation for simplification with core build. The non-MBS Make build is CDT <= 3.0 which still has remnants in the code base today :(

Marc-André

> On Dec 9, 2020, at 4:03 PM, Martin Weber <fifteenknots505@xxxxxxxxx> wrote:
>
> On Mittwoch, 9. Dezember 2020 00:29:42 CET Liviu Ionescu wrote:
>>> On 9 Dec 2020, at 00:56, Martin Weber <fifteenknots505@xxxxxxxxx> wrote:
>>>
>>> Well, after 7 year of driving through CDT code base: It depends on being a
>>> masochist or not :-)
>>
>> Actually the question was different: is CDT without MBS, at this moment,
>> able to support something functional? In other words, if I start a new
>> build plug-in based on CDT without MBS, can I get multiple build
>> configurations and a functional indexer, or I have to patch/rewrite half of
>
> IIRC, CDT currently has three build systems:
>
> - Makefile project:  Users have to maintain their buildscripts. Users have to
> teach the indexer about include paths and macros.
>
> - MBS aka Managed (Makefile) Build System: CDT generates the build-scripts for
> users. CDT itself provides buildscript-generation for the 'make' build tool
> only. Tries to teach the indexer about include paths and macros by parsing
> build output (focused on gcc). Users may additonally to teach the indexer
> about include paths and macros.
>
> - The thing called 'core build'. Its javadoc is poor, and there are no concept
> papers explaining what it is supposed to do and the author is no longer with
> us.  Tries to teach the indexer about include paths and macros by parsing
> build output (focused on gcc). Provides no mean for users to teach the
> indexer.
>
> CDT-cmake, CDT-meson and CDT-qt?? are based on that core-build thing.
>
> CDT-cmake feeds include paths and macros specified in the user's 
> CMakeLists.txt files to the indexer. If the compiler supports built-ins-
> detection, it feeds that to the indexer, too. If not, users cannot teach the
> indexer, ATM.
>
> Martin
>
> --
> Cd wrttn wtht vwls s mch trsr.
>
>
>
>
> _______________________________________________
> 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