RE: Tool chain for RTEMS 4.11
Why not just automatically update the RTEMS-Source-Builder? Not everyone will use the RSB, and we prefer it that way. Correct. We need developers to know how to build the tools manually so that we maintain the expertise to improve the tools source code... It's OK as a test bed, but it's not suiteable as a means of proper system integration. I know this sounds cheeky, but... Proper systems integration comes from integrating systems (which is what RSB does)... We are in the process of trying to add automated intregration testing to the RTEMS Source Builder... I'm planning on starting with a build-set to integration test gdb (as that's probably easiest, and move onto binutils next...) Right now, all we can do is run RSB and then manually do run-time simulation testing... Providing RPMs or any other nicely packaged binaries for a particular host is a nice thing to do. But each packaging format is a point solution for a particular OS, version, host CPU, target processor, and tool versions. If we provide binary packages, they need to be tested on the host OS's and test-results submitted to gcc-testresults before we provide them for public use (systems integration :). They need to install properly on the host no unsolvable dependencies, and they also need to be able to build all rtems executables for all rtems targets... It does not address a number significant number of issues: + What about OSes which don't make the binary support list? That's a great reason to also know how to build manually, (in addition to RSB)... what if it's not supported by RSB? + What about users who need a patch that is not officially supported? + What about users that want anything vaguely resembling long term configuration management on their tools? Configuration management is another part of systems integration :) + What about users who need to build the libraries with specific flags? That's another great reason to also know how to build manually, (in addition to RSB)... We can not and will not force RTEMS users to particular host OS solutions. +1 There has been a concerted effort to submit all patches upstream in a timely manner. Queues of older patches have largely been cleared and we can use close to vanilla upstream source. You are not using the version and patches the community wants to use. If the RPMs are to have any value, then they need to be adjusted to match the community requirements. Yes, the community needs to keep current, the head is where the long-term bug-fixes are... We upstream patches promptly so we can stay current without a lot of developer overhead... by not upstreaming patches, cross-rpms appears unable to use the current newlib... ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Tool chain for RTEMS 4.11
On 2013-07-16 09:34, Rempel, Cynthia wrote: Moving forward we should keep patches separated in such a way as they are easier to upstream, this will require an update to the http://www.rtems.org/wiki/index.php/Building_Tools tutorial, but hopefully, updating the tutorial won't be too difficult. Why not just automatically update the RTEMS-Source-Builder? Just one tool to update, and people wouldn't even notice new updates. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
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? 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. -Gedare On Tue, Jul 16, 2013 at 11:34 AM, Rempel, Cynthia cynt6...@vandals.uidaho.edu wrote: I agree. We need to agree on toolchain versions before rolling out with a release, and we really want as many patches as feasible upstreamed as soon as feasible (to maximize the probability they will be commited) and, where feasible, we want toolchains for the targets to be up-to-date as well. I know in the past some of the targets require special versions, so for the targets that still have problems during the feature freeze, we'll have to adjust for needing special toolchain versions. So I would like to propose before settling on which version to use for a given target, we verify the current toolchain version works... and if not, we make a determination of the most current version that does work. Moving forward we should keep patches separated in such a way as they are easier to upstream, this will require an update to the http://www.rtems.org/wiki/index.php/Building_Tools tutorial, but hopefully, updating the tutorial won't be too difficult. We really do want just one set of patches, as opposed to having rpms and rtems-tools (and that all pathces out for users have been submitted for upstreaming)... I also would like to propose we set a TENTATIVE feature freeze for the RTEMS kernel of Mid-October, through Mid-November -- if we integrate Summer of Code contibutions as we go, this will be enough time to integrate the features before we freeze them... then we could schedule the release to happen before contributions pick up over the holidays... with Mid-November as the TENTATIVE release date... this would also increase the probability that the tool chain patches we have now will be in the upcoming releases of the tools. This would mean features could be added until Mid-October... Thanks, Cindy From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] on behalf of Sebastian Huber [sebastian.hu...@embedded-brains.de] Sent: Tuesday, July 16, 2013 5:11 AM To: RTEMS Subject: Tool chain for RTEMS 4.11 Hello, before we release RTEMS 4.11 we have to agree on the tool chain versions (Binutils, GCC, Newlib, GDB). Currently the RTEMS developers are a bit divided with respect to the tool chain in use. We have the RTEMS source builder based versions and we have the RPM based ones. The RPM based ones use patches which can be found here: http://git.rtems.org/rtems-crossrpms/tree/patches The Newlib patch is quite huge and an explanation for it can be found here: http://www.rtems.org/pipermail/rtems-devel/2013-March/002686.html I propose the following actions: 1. Submit all RTEMS tool chain patches for review to the rtems-devel list. The time frame for this should be two weeks. 2. After review (after two weeks without response assume that the patch is all right) submit the patches for upstream integration. Patches from people without a FSF copyright assignment are problematic here. 3. After all patches are integrated upstream select an upstream snapshot version for the RTEMS tool chain release candidate. 4. Propagate the changes to the developers. 5. Adjust the RTEMS sources accordingly. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
RE: Tool chain for RTEMS 4.11
From: Joel Sherrill [joel.sherr...@oarcorp.com] Sent: Tuesday, July 16, 2013 1:44 PM To: Rempel, Cynthia Cc: Gedare Bloom; RTEMS Subject: Re: Tool chain for RTEMS 4.11 FWIW * 2012-12-20: newlib-2.0.0.tar.gzftp://sourceware.org/pub/newlib/newlib-2.0.0.tar.gz (15MB) * 2011-12-19: newlib-1.20.0.tar.gzftp://sourceware.org/pub/newlib/newlib-1.20.0.tar.gz (14.5MB) * 2010-12-16: newlib-1.19.0.tar.gzftp://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. Wow! Thanks! I agree... ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Tool chain for RTEMS 4.11
Joel Sherrill wrote: 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. I agree. I have no interest in chasing shadows. Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Tool chain for RTEMS 4.11
Gedare Bloom wrote: Sebastian, are you proposing to submit the tool patches to the rtems-devel list, or are you expecting/hoping that someone else will? The rtems-tools.git repo is the official location of patches for the tools. It is independent of packaging and packagers and how these patches are integrated in a specific packaging system is the responsibility of the packager. All tool patches should be placed in the rtems-tools.git repo. Patches need to be specific and relate to a single issue. No jumbo patches. Architecture specific patches should be placed in an arch specific directory. As far as I know all outstanding patches are in this repo. Newlib patches are all in newlib's CVS repo. A formal tools release for 4.11 requires we snapshot the newlib CVS repo at a specific point then move to patches in rtems-tools.git for critical updates. 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. I am not so sure. We will never reach a point where a branch can be made unless as avoid commits that are not needed or not stable. If a commit enters the repo as a new feature, partially implemented or tested just before the branch then we could release something is not in a suitable state. Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
RE: Tool chain for RTEMS 4.11
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. I am not so sure. We will never reach a point where a branch can be made unless as avoid commits that are not needed or not stable. If a commit enters the repo as a new feature, partially implemented or tested just before the branch then we could release something is not in a suitable state. Chris Could we do the feature freeze from Mid-October to Mid-November (as that's when there's a high probability of a lull in development?) ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Tool chain for RTEMS 4.11
On 07/16/2013 10:44 PM, Joel Sherrill wrote: 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. Joel - Why can't you resist from being rude? I think you believe to be polite with what you wrote above, but it's not how I perceive it. What you are missing: Unlike newlib-CVS which has undergone a lot of mostly untested aggressive and questionable changes with mostly untested outcome, this patch works. Ralf ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Tool chain for RTEMS 4.11
On 07/16/2013 10:44 PM, Joel Sherrill wrote: 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. The problem with newlib is newlib being very volatile and newlib-2.0.0 having been a snapshot of what was current then and it *NOT* having been stable snapshot. That said, the version numbers are mostly moot. What would be required here is a hand-crafted merger with newlib-CVS. Unfortunately, this is very tedious, error-prone and requires a lot of time. Ralf ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Tool chain for RTEMS 4.11
On 07/16/2013 05:49 PM, Gedare Bloom wrote: On Tue, Jul 16, 2013 at 11:45 AM, emanuel stiebler e...@e-bbes.com wrote: On 2013-07-16 09:34, Rempel, Cynthia wrote: Moving forward we should keep patches separated in such a way as they are easier to upstream, this will require an update to the http://www.rtems.org/wiki/index.php/Building_Tools tutorial, but hopefully, updating the tutorial won't be too difficult. Why not just automatically update the RTEMS-Source-Builder? Not everyone will use the RSB, and we prefer it that way. Correct. It's OK as a test bed, but it's not suiteable as a means of proper system integration. Ralf ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
