On Thu, Mar 26, 2020 at 11:04 AM Gedare Bloom <ged...@rtems.org> wrote:
> On Thu, Mar 26, 2020 at 9:40 AM Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Thu, Mar 26, 2020 at 10:17 AM Gedare Bloom <ged...@rtems.org> wrote: > >> > >> On Thu, Mar 26, 2020 at 7:28 AM Joel Sherrill <j...@rtems.org> wrote: > >> > > >> > > >> > > >> > On Thu, Mar 26, 2020 at 2:26 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> >> > >> >> On 26/03/2020 07:54, Chris Johns wrote: > >> >> > >> >> On 2020-03-20 14:57, Chris Johns wrote: > >> >> > >> >> Only having sources in `sources` is a change from how RTEMS has been > released in > >> >> the past so I feel this needs to be discussed and approved before I > make any > >> >> changes. > >> >> > >> >> > >> >> I will place all source in `sources`. > >> >> > >> >> Sorry I missed this email. Placing the sources in a directory is an > improvement from my point of view. > >> > > >> +1 > >> > >> > > >> > Does this mean you will end up with one source tarball with every > repo in it? > >> > > >> A release contains basically a snapshot of all source code that goes > >> into it, including tools. The 'sources' directory will contain all of > >> those snapshots, each one a tarball of the respective source (e.g., > >> automake-x.y.z, rtems-x.y, etc.). > >> > >> Look at the 4.11.3 release for an example of how it was being done: > >> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/ > >> > >> See that there is a sources directory, but that we also put "our" > >> source in the top-level. Chris' plan is to also put the rtems-*.tar.xz > >> underneath sources/ > > > > > > Hmm.. Why would we mix RTEMS originated source packages with > > third party source and patches. This directory is already quite lengthy. > > > > I must have missed the clear statement of what the advantage is. > > > > The advantage is that all the source that belongs to the release is > consolidated. all rtems packages are prepended by rtems- so they are > still easily identifiable in the sources subdirectory. > > Ideally, the readme will simply direct the user to run the > script/command necessary to build things :) I think this is simpler, > and users will still be able to find specific sources as they need by > looking in one place. > Then the readme for the release should have some basic information for pointing into this and finding instructions to build for a target. Not much more than pointing into telling them to (hopefully) untar the docs and start at section X in the Users Guide for host setup and section Y for building the RTEMS Ecosystem. Assuming the readme gets people one link down the chain into the Users Guide and the Users Guide is complete from there. > > >> > >> (I discussed with him briefly before, and am in favor of this > >> approach, but held my vote :)) > >> > >> > --joel > >> > > >> >> > >> >> _______________________________________________ > >> >> devel mailing list > >> >> devel@rtems.org > >> >> http://lists.rtems.org/mailman/listinfo/devel > >> > > >> > _______________________________________________ > >> > devel mailing list > >> > devel@rtems.org > >> > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
