Tool chain for RTEMS 4.11

[Joel Sherrill]

FWIW

  * 2012-12-20:newlib-2.0.0.tar.gz
    <ftp://sourceware.org/pub/newlib/newlib-2.0.0.tar.gz>(15MB)
  * 2011-12-19:newlib-1.20.0.tar.gz
    <ftp://sourceware.org/pub/newlib/newlib-1.20.0.tar.gz>(14.5MB)
  * 2010-12-16:newlib-1.19.0.tar.gz
    <ftp://sourceware.org/pub/newlib/newlib-1.19.0.tar.gz>(14.3MB)

newlib 1.20.0 was released almost 20 months ago.
newlib 2.0.0 was released about 8 months ago.

The diff in git is dated March 2013. Newlib has been
very active. Everything from the RTEMS Community
SHOULD have been submitted.

FWIW I hacked on diff. Started at 70K. Being brutal...
I threw away generated files, ChangeLog changes,
license text changes, new ports (some RTEMS doesn't
even support), and libgloss changes and got it down
to 20.8K lines.

If there is anything in this patch worth using, the author
of the patch should speak up. Otherwise, I personally
am writing if off as a cvs diff on an arbitrary date and
ignoring it.

On 7/16/2013 2:51 PM, Rempel, Cynthia wrote:
>> ________________________________________
>> From: gedare at gwmail.gwu.edu [gedare at gwmail.gwu.edu] on behalf of Gedare Bloom [gedare at rtems.org]
>> Sent: Tuesday, July 16, 2013 8:46 AM
>> To: Rempel, Cynthia
>> Cc: Sebastian Huber; RTEMS
>> Subject: Re: Tool chain for RTEMS 4.11
>>
>> Sebastian, are you proposing to submit the tool patches to the
>> rtems-devel list, or are you expecting/hoping that someone else will?
> FWIW, I think we'd need a strategy for breaking up the gigantic newlib patch (if we want to try to upstream it)...
> probably need to use scripts...
> some steps for dealing with the patch that come to mind are:
> 1. split the patch up by the files being patched
> 2. throw out patches that apply to files that are autogenerated (such as configure)
> 3. throw out all diffs that were already applied
> 4. estimate the number of patches left to consider
> It may turn out not to be that many lines of code to review...
>
>> Cindy (and others): A feature freeze is fine to talk about, but I
>> don't think we need an actual freeze. We can just cut a 4.11 branch
>> and treat it as a (pre)release branch with release branch rules---bug
>> fixes only. Then the git master branch can continue development under
>> the next version cycle.
> Not slowing down development sounds great :) Yeah! We could do the branching at any time then...
> Although before we do, we may want to think about if we want to wait a little longer for a lull in the development cycle (i.e. after the Summer of Code)...
> We could also consider putting the release procedures in asciidoc (or some other standard) format in rtems.git and rtems-tools.git...
>> -Gedare
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130716/02bd6ff6/attachment.html>