On 2020-03-27 03:43, Joel Sherrill wrote:
On Thu, Mar 26, 2020 at 11:04 AM Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
On Thu, Mar 26, 2020 at 9:40 AM Joel Sherrill <j...@rtems.org
<mailto:j...@rtems.org>> wrote:
> On Thu, Mar 26, 2020 at 10:17 AM Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
>> On Thu, Mar 26, 2020 at 7:28 AM Joel Sherrill <j...@rtems.org
<mailto:j...@rtems.org>> wrote:
>> > On Thu, Mar 26, 2020 at 2:26 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto: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.
I pushed on because no one said anything so I assumed the change was fine.
Currently the source for a release is in two places, the `sources`
directory, and the top level directory. This means the RSB has to be
configured with both paths in a release. If the source being fetched is
in the top level directory it has to look into the `sources` directory
and fail before moving to the next path in the configured list, i.e. the
top level directory. This generates an error message and this can be
confusing to our users.
I am looking into the detail and I will try all the source in the one
directory.
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.
This is the current README.txt ...
https://git.rtems.org/rtems-release/tree/README.txt.in
The Release Files section will need to change and the documentation will
also need to change. I will trial a snapshot before looking to update
the documentation.
Assuming the readme gets people one link down the chain into the
Users Guide and the Users Guide is complete from there.
I am not sure what this means. Are you able to clone releases repo and
show me how you do this?
Chris
>> (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
