On Wed, Nov 15, 2017 at 4:35 PM, Chris Johns <chr...@rtems.org> wrote:
> On 16/11/2017 08:37, Jacob Saina wrote: > > Thanks, I'm much better than I was yesterday. > > > > Good to hear. > > > I attempted a build of the 4.11.0 release of RSB from here > > (https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.0/) on the same > Windows 10 > > machine using the --without-rtems flag, and I get a build failure on the > same > > thing, after 30 minutes: > > Build: error: building arg4n2xwm1 > > I am attaching the error report from yesterday building 4.11.2, as well > as > > today's from 4.11.0. > > Please use 4.11.2, 4.11.0 is known to be broken. > > My build got lost, Windows 10 decided to update and restart over night even > after attempting to configure it not too. > FWIW I had a sparc build go ok for the master on Windows but tried a powerpc build and it failed with something about unable to fork. I am restarting it and letting it run again. > > > A clarification regarding the older Windows machine that was able to > build > > 4.11.0 -- I learned that that was using git, and checking out the 4.11.0 > tag, as > > opposed to downloading the release tarball. Maybe that is relevant. > > I think 4.11.0 is not worth any effort and 4.11.2 is. Anything we find on > 4.11.2 > can be put on the 4.11 branch and 4.11.3 can be released. I am starting to > look > at what is needed for 4.11.3. > > I have been considering the default of building the RTEMS kernel when > building > the tools as a result of what you have been reporting so thank you for > taking > the time to do this. > > In theory it is a good idea however some archs have too many BSP and the > time > and resources it consumes makes this problematic. It may be simpler to not > build > the RTEMS kernel and to make sure the documentation and Quick Start in the > release details how to build the kernel. This way the tools get built and > installed as a step and then the kernel can be built as a second step. At > the > moment any failure means no tools and kernel and that is not great or user > friendly. > I think building RTEMS by default is a bad idea for a few reasons. + First, you are building everything which takes a long time and a lot of disk space. It is common to run out of disk space while building BSPs you don't care about. I am teaching a class this week and at least one person ran during the RSB build and another forgot --enable-rtemsbsp and ran out building RTEMS. It also took a long time. + Second, it may not be the configuration the end user wants even if the BSP they want is in the list. + Finally, if they are going to develop a new or work on an existing custom BSP, then they are interested in building none of the existing BSPs in the tree. I just don't see the need to build all the BSPs when you build the tools. > > > Additionally, I have trouble finding these pages to download releases > from, like > > the one linked above, as they seem not to show up in search engine > results. I > > always find pages like this (https://devel.rtems.org/wiki/Release/4.11). > What's > > the typical way of navigating to them? > > Wiki's are hard to maintain and things have been moving around lots. > > In an attempt to make a single simple place to handle this I have added to > the > top page of the Wiki a Releases table. A click on a bookmark to the wiki > brings > you to this table and it is at the top so it should always be visible > without > scrolling. > > The table contains the releases the RTEMS project publicly supports. > Currently > this is 5, 4.11 and 4.10. The project supports the development branch (git > master) and the previous two releases. Other releases may have work done > on them > based on commercial support efforts. > > The table contains a Download column and clicking on that link should take > you > to the download directory for the release. This is a second click. > > There is also a link to the Documentation and a link to create a bug for > that > release. Each a click from the top of the wiki page. > > The first column takes you to the Release Notes page which is a top level > wrapper for the dot point release notes. The dot point release notes are > captured in a PDF by the release process and placed in the release > directory. > > I hope this helps. > +1 If there repeatable problems against the last releases on any active release branch, please file tickets and let us know. --joel > > Chris > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
