|Re: [cdt-dev] CDT Monthly Call
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 configurationThe main pains I have encountered are:
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)
- 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.
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.
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:
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.
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 CallAm 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
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
- 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)
Cd wrttn wtht vwls s mch trsr.
cdt-dev mailing list
Renesas Electronics Europe GmbH
Registered Office: Arcadiastrasse 10
Commercial Registry: Duesseldorf, HRB 3708
Managing Director: Carsten Jauch
VAT-No.: DE 14978647
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
cdt-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Back to the top