Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT Monthly Call

All

Just for the record:

I have been rewriting MBS for over a year now and have made significant progress.

Some of the MBS limitations that are already fixed are:

  • I added a project type that supports for building static libraries, dynamic libraries and one executable in one build. (based on the folder structure of the project)
  • No storage of Locally generated id's in persistent files (making it easier to use version control)
  • Internal build and make build start from the same basis and run the same commands making switching between the 2 seamless.
  • There is no more build artifact in the project properties. You can change the build artifact by changing the project type.
  • In MBS configurations defined in plugin.xml can only be selected at project creation time. New MBS allows you to change the configuration defined in plugin.xml that is used as a basis for a given configuration 
The main pains I have encountered are:
  • My lack of knowledge on eclipse integrations and how MBS/CDT uses/integrates with eclipse plugin XYZ.
  • Lack of knowledgeable person to ask about these integrations.
  • Lack of documentation of the API to integrate with CDT.
  • Lack of knowledgeable person to ask about MBS internal workings.
  • Lack of sufficient support of CDT to help out on issues/questions.
  • Degradation of code quality of MBS over time (Think about what Java and eclipse looked like 17 years ago. The good stuff ripped out of MBS while all the bad stuff is still there).
  • MBS using the plugin.xml model as default project and as storage model (in the .cproject) at the same time.

Anyone willing to change/adopt/extend MBS will meet these pains in some degree. (read after you have done lots of work you will find out there is a way easier/better way)

I do not advice anyone on which road they should take. I do want to share my experiences on the relevant roads I took; in the hope it increases the changes of others to succeed.

Best regards
Jantje

Screenshot of new MBS that shows how you can change the project type (and as such the build artifact) and/or the underlying configuration defined in the plugin.xml

Op 18/10/2023 om 0:19 schreef William Riley via cdt-dev:
Hi Martin

What we (Renesas) are looking at is generating compile-commands.json based on the managed build data for a project.

We are not planning to implement a cmake generator for managed build. Just the json file for existing MBS make & internal builder projects.

Regards
William

From: cdt-dev <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Martin Weber via cdt-dev <cdt-dev@xxxxxxxxxxx>
Sent: Monday, October 16, 2023 9:27 pm
To: cdt-dev@xxxxxxxxxxx <cdt-dev@xxxxxxxxxxx>
Cc: Martin Weber <fifteenknots505@xxxxxxxxx>
Subject: Re: [cdt-dev] CDT Monthly Call
 
Am Mittwoch, 11. Oktober 2023, 19:33:53 CEST schrieb Jonah Graham via cdt-dev:
> Hello folks,
>
> Thanks for coming to the call today. I enjoyed the call and getting to talk

OK, I admit I should not have missed that call.

> to you all! Here are the minutes of the meeting:
...
>       - Renesas is looking to restart the work of compile_commands.json for
>       Managed Build project in the coming weeks

Huh, MBS is not dead? OTOH, CDT core build seem to be not really alive:-)

Parsing the compile_commands.json file for better support of the indexer is
already part of CDT in class
org.eclipse.cdt.jsoncdb.core.CompileCommandsJsonParser.

If Renesas is willing to throw in man-power for better indexer support and
cmake support by MBS, they might want to save afford.
- My MBS-based cmake4eclipse plugin shows how to integrate the
CompileCommandsJsonParser.class into MBS for indexer support.
- Renesas could decide to become co-maintainers of cmake4eclipse (or adopt its
parser for CDT).

Anyway, IMHO the problems with MBS are:
- It is an experiment to generate build scripts based on stuff edited in a
GUI.
- Its GUI (and default makefile-build-script-generator) allows users to
specify to build *one* artifact per project only. Gives top user-experience
for a hello-world project, but if your project is 'Compiler with its
accompinying runtime libs' it gets cumbersome.
- MBS theoretically allows vendors to integrate a build-script-generator that
gets its configuration from a file but users will still be be confused by
project property tabs that have no effect (e.g. *project artifact* settings)

Regards,
        Martin
--
Cd wrttn wtht vwls s mch trsr.




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx

Renesas Electronics Europe GmbH
Registered Office: Arcadiastrasse 10
DE-40472 Duesseldorf
Commercial Registry: Duesseldorf, HRB 3708
Managing Director: Carsten Jauch
VAT-No.: DE 14978647
Tax-ID-No: 105/5839/1793

Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top