Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [embed-cdt-dev] EPP

Hi Liviu and All,

I think the first release should be done with whatever way works better for you at the moment. The public URLs are also is not that important as you always can redirect them to the better location (that is not invented yet) using "composite p2 repository" approach.

After the first release I would propose to prepare another package for EPP. EPP already has several packages that duplicates functionality but with different focus - so I think that introducing another package "Eclipse IDE for Embedded Developers" could be the right way to go forward. Yes, it can share about 90% of its content with "Eclipse IDE for C/C++ Developers" and I do not see any problem with it.

As for " content inheritance" - I'm not a fan of inheritance, mostly because it is "one way ticket" and you cannot "uninherit", so I would suggest to use feature composition. I hope we always can find a way to declare a proper aggregating feature(s) on CDT side to decrease the amount of duplicated identifier between "C/C++" and "Embedded" packages.

Another plus for joining the EPP will be the reducing of effort duplication for package publishing. Well, to be honest, it may create more work for Jonah as he is co-leading EPP. But Jonah is doing RelEng work here as well, and from the outside it looks like adding another package to EPP is much cheaper than introducing and maintaining the individual "package support" for "Embedded CDT". Jonah, please correct me if I wrong.


25.07.2020 21:34, Liviu Ionescu пишет:
I updated the EPP fork that I used in the past, and the build passed, I was able to create the new packages for 2020-03 with 5.1.1.

I tried to figure out what would be the next step, but could not find a clear answer.

As it is now, the EPP configuration I use is a slightly changed epp.package.cpp where I added the GME features and some small branding fixes.

The first thought was to create a new configuration (epp.package.embedcpp?) and apply the changes there.

Copy/paste for the three projects would probably not be difficult, but maintaining it in sync with future changes in the .cpp projects will.

Also considering the future SimRel integration, what would be the proper solution? Ideally the .embedcpp would inherit from .cpp and change a few things, but I'm not sure such a configuration is possible.

I am tempted to stick to the current EPP fork solution, and for the moment focus on the changes to run the build on Jenkins, so I can sign the resulting packages and publish them on the download servers.

Another issue: I don't know how to handle the location of the released packages. Ideally this location would not change after joining SimRel, but this might not be possible.

Is it ok to publish the results on something like ''?

Alexander, any thoughts?

Thank you,


embed-cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top