|
There is currently no committer dedicated to managed build and there hasn’t been one for a long time. Any change request in that area must be accompanied with a lot of JUnits to give the rest of us confidence that the change fixes the problem and doesn’t
cause regressions.
I'm always interested to hear different people and companies rely so heavily on managed build. This is an open project and it only succeeds if we have those with vested interest contribute to the those things and help rebuild the community.
Doug.
Jonah
Thanks for taking this seriously.
I think I acted upon all your requests now.
>However on a general point the code changes you are talking about I believe are exactly in the place that Doug has listed as possible deprecation targets:
Here is my point of view:
As far as I know the GnuMakefileGenerator is currently the only way to work with self generating makefiles.
I understand that CDT wants to go ahead and GnuMakefileGenerator is legacy that can use a serious brush-up (softly speaking).
However, I find it hard to accept that the current code is about to become marked as deprecated when the new code is still in development
and has not yet proven it can handle the complexity and feature richness the current code has become over years.
My advise: Lets look at the future and embrace what it brings; but lets not deprecate the people who use and support CDT for what it is now.
>hopefully meaning you can reintegrate your custom copy of GnuMakefileGenerator and no longer need it separately.
Unfortunately not. I have changed my copy for things that I can not sell as "bug fixes" (like the sequence of building starting with the root folder) and more seriously providing the project to the LanguageProvider calls (which was vital to support Arduino's
way of working).
>From this and other projects I learned that API java classes (with the currently commonly used programming rules) are hard to extend.
In this case I need to modify fields and methods that are marked private (and the fields do not have getters). Therefore extending will never get me there :-(
I pushed those changes as I prefer my version to be as close to CDT version as possible so it is easier to find changes done by CDT.
Also I lost lots of time in plugin.xml trying to get CDT to do what it promised to do (with the multiple inputs and outputs) and never did.
I hope to safe some else his/her time here.
On a very practical level I pushed these changes as I was so happy I finally got to install and compile CDT. I have been wanting to contribute for a longer time but could never do more than bug reporting as I always failed to compile CDT.
The GnuMakefileGenerator is the one that I care about the most because: The rest just works fine (thanks for that) and/or gets more attention.
Best regards
Jantje
Op 6/11/2016 om 21:04 schreef Jonah Graham:
Hi Jan,
I have taken a look at your gerrits and provided some feedback there.
However on a general point the code changes you are talking about I
believe are exactly in the place that Doug has listed as possible
deprecation targets:
https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg31311.html
I think Doug can comment more here if needed, but my feeling is that
the managed build/makefile generator code has always been extensible
in such a way that extenders can simply replace any component that
does not do what they need (either to work around bugs or otherwise).
The result being that not many people have contributed back their
customisations. I am grateful for you contributing back these fixes,
hopefully meaning you can reintegrate your custom copy of
GnuMakefileGenerator and no longer need it separately.
Thanks
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
On 6 November 2016 at 18:07, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi Jan,
Can you please ping the mailing list for the gerrits you did that have not
been reviewed (please rebase them to current master too, often a click or
two in gerrit).
It sometimes does take time to get someone to review. And by time I really
mean determination and a little bit of of pinging on the mailing list.
One of the real challenges faced is that for some components of CDT none of
the current committers are very invested in them, but consumers and
extenders still are. We need those extenders and consumers!
Thanks,
Jonah
On 6 Nov 2016 5:49 p.m., "Jan Baeyens" <jan@xxxxxxxxxx> wrote:
Don't hold your breath though.
In November 2013 I also asked whether it was worthwhile to report some
bugs/fixes I had posted in this forum, and whether I should do 1 bug or 3.
Someone answered yes and make separate bugs. So I made 3 of them.
Nothing was done with these bugs untill now. They are not even on the cdt
bug list that is send to this mailing list.
When I finally succeeded in setting up a cdt development environment (thanks
to oomph) last month I decided to fix the 3 bugs. I pushed to gerrit on
Oktober 21 2016.
As far as I know nothing was done with the push till now.
Jantje
PS I'm sorry to sound so negative but as a developer of the Arduino eclipse
plugin named Sloeber I have some serious experience with CDT and I feel that
I can contribute good things. (Like the issue 372807 I reported in 2012
which was a hot issue somewhere earlier this year)
I think CDT is really good and the real power behind Sloeber, but just like
many other open source projects, it is hard to have even a very small change
implemented in CDT when you are not ... (well I don't know, maybe it is just
hard for everyone)
Op 6/11/2016 om 11:26 schreef Jonah Graham:
Hi,
Thanks for reading the documentation!
Reporting the bugs is useful, but providing patches is useful too :-)
I would be pleased to review and/or help you setup on contribution
process.
For documentation that is at help.eclipse.org and embedded into the
product, contributions are via git[1], see this process
https://wiki.eclipse.org/CDT/contributing.
For FAQ and wiki stuff, just edit the wiki[2] Note that the first few
edits are moderated.
[1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/doc
[2] https://wiki.eclipse.org/CDT/User/FAQ
Thanks for the help!
Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
On 6 November 2016 at 00:51, Oodini <svdbg___@xxxxxxx> wrote:
Hello,
I am on the page listing the bugs declared for the cdt-doc component, and
most of them are several years old.
As I intend to read the full documentation, should I report all the errors
I'll find ? Will it worth it ?...
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
