| Re: [cdt-dev] Is there interest in a rewritten managed build? |
Hi John
Thank you for showing interest. ;-)
I'll try to answer your questions as good as I can.
Why did you need to modify the CDT managed build system (MBS) extension point schema?
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>)
So I decided to completely rewrite gnuMakeFileGenerator to get
that to work. However doing so I learned this was a extension
point schema limitation. I also noticed some other things that
made me want to change the extension point. So to list them:
1) output type assumes multiple extensions/names but you can have
multiple output types for the same tool which seems redundant to
me.
2) I did not see a way to reuse an extension point field to code
the "assign to command variable" what I needed to fix the problem
described above.
3) the primary input and output make no sense to me at all.
4) Nor does the multiple of type
5) confusing names: outpuType->outputs is actually a list of
file extensions
6) To mutch unfinished business
As we all know the quality of the implementation of MBS has
degraded over the years and I have been looking at rewriting it
for some years now. To me this was the drop that made the bucket
overflow; so I decided to try to rewrite MBS fully.
As I realize this is a daunting task (with limited success rate
expectations) I first wanted to get enough confidence in pulling
this off before talking about it.
How does the feature set of the revised MBS differ from that of the existing CDT MBS?
I try to keep the feature set as close as possible. However:
* If this is not going to be -in some way or another- part of CDT
I will solely focus on getting Sloeber to work.
* I doubt some features ever worked (properly) (like editing the
extension point in the gui)
* As there will be an extended transitionary period where both
will run in parallel there is some renaming involved
* As the feature set is extensive it is nearly 100% sure at least
some features will have disappeared. As we will have a cleaner
code base adding these features should be easier. (No guarantees)
The rules I have acted upon right now are:
1) For the model a output Type is one file with 1 name or 1
extension (multiple files need to be modelled with multiple output
types)
2) Remove primary input/output
3) removed multiple of from the model
4) remove everything deprecated.
5) Remove editing of the model (I mean Sloeber reads the selected
model from file and works with that. No ad runtime adding/removing
of input types/tools .... ; Selecting a different extension point
is on the table)
6) support for multiple extension points and extension point
schemas (I see this as the best way to handle versions)
7) Remove the current version code
8) The interface classes of the providers to the model are open
for change (and some have already)
9) The generated makefiles are a technical step so they do not
have to be human readable.
10) Environment variables and build variables are used via
cdt.envvar
Stuff that I would delete if it was a Sloeber only thing but I'm
open to discuss if it is part of CDT are:
1) removal of toolchain (note toolchain is used for multiple
things; here I refer to cross gcc; microsoft visual C+++, gnu win
...); Use a environment variable to point to the toolchain binary
path
2) removal of internal builder
3) removal the cross compiler prefix
4) The sense and nonsense of build variable provider next to an
environment variable provider
5) disablement of make file generation.
6) removal of outputType->namePattern
7) remove additional inputs from the extension point schema
How does the user interface differ from that of the existing CDT MBS?
User interface is not my thing so I hope to be able to reuse as
mutch of it as possible. However the stuff described above will
have GUI impact.
To me it would be great if CDT created a "scanner config nature"
and an "environment variable nature" that would activate the user
interfaces for these parts. These components are active in my code
right now but not visible in the gui.
The MSB specific stuff I'm rewriting
1) a different project creation wizard
2) The toolchain editor will be removed
3) Hopefully a "extension point selection" page will be added.
4) The MSB pages will have to be moved/refactored as they work on
different classed and previous work may have created
incompatibilities.
How I look at autoBuild
I think the makefile generation is a technical part of the build.
Therefore :
* A clean should not be the clean of make but delete all the build
output including the generated makefiles. (In Sloeber a clean is
not always enough)
* The makefiles do not have to be human readable.
* There is only one way to create make rules. (FI current
implementation allows support for * or explicit file listing.
AutoBuild only support explicit file listing)
* There should be only one makefile
Don't forget this is a long and difficult project. I may know
where I am today and I may think I know where I hope to end up;
but "Man proposes, God disposes.". This puts me on a difficult
balancing point between using as little resources of CDT team as
possible and still get enough input.
I guess this is enough for now.
Best regards
Jantje
Hi Jantje
To help us all respond to your question, can you please briefly comment on the following points:
- Why did you need to modify the CDT managed build system (MBS) extension point schema?
- How does the feature set of the revised MBS differ from that of the existing CDT MBS?
- How does the user interface differ from that of the existing CDT MBS?
Regards
John Dallaway
On 01/01/2023 20:32, jan wrote:
Hi all,
I have been working on rewriting part of managed build. That is; I needed a new extension point because I needed to modify the extension point schema.
I have gotten to the point where I have the basic framework -based on the original code- running from a different extension point (io.sloeber.autoBuild.buildDefinitions).
There is still plenty of work (months to a year I think).
The steps I plan to take are
- Copy/modified code to get the basic framework to run. (done)
- get a functional part working
- add runnable tests (used for regression testing)
- cleanup/rewite the functional part.
- If parts remaining goto 2
During cleanup I will have to take important decisions that will decide on the reusability.
I'm thinking about
- Do I keep the toolchains, the versions, the build variables...
- How far to cleanup the extensionpoint
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".
Therefore I would like to know whether there is interest in this?
Best regards
Jantje
The current mess of code can be found at https://github.com/Sloeber/arduino-eclipse-plugin/tree/%231126_support_for_creating_library_archives
The 2 plugins you need to add to CDT are io.sloeber.ManagedBuild and io.sloeber.ManagedBuild.ui
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev