| Re: [cdt-dev] CDT Monthly Call |
Hi John
>but I didn't catch the initial conversion on what you're trying to solve.
My basic driver is a requirement for Sloeber that I wanted to solve with a change in the extension point schema.
I described it as:
The current gnuMakeFileGenerator always put input files at the same place. To really support the Arduino framework Sloeber has to put the input files of the type archive on the command line on a different place from the input type object files during link time.
link <bla bla> ${archives} <more bla bla> ${object files} <Another bla bla> ${output files} <last bla bla>
As to the scope of what I wanted to take along: I described as:
An important driver for me will be: "Will this ever become part of CDT" because if not the only criteria is "Does sloeber need this".
But in reality I see that I'm porting most of MBS (or at least the part I know) which also explains I won't be ready end this year.
>Maybe you would consider giving a demo and a summary of the features sometime?
sure. I love feedback.
Jantje
Hi Jan,
That all sounds very interesting. I saw a while ago that you were working on this, but I didn't catch the initial conversion on what you're trying to solve.
Maybe you would consider giving a demo and a summary of the features sometime?
Cheers John
On Wed, 18 Oct 2023 at 14:35, Jan Baeyens via cdt-dev <cdt-dev@xxxxxxxxxxx> wrote:
_______________________________________________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: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.
Best regardsJantje
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.
RegardsWilliam
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/1793Legal 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
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
