Rtems-core Binaries

[Joel Sherrill]

Ralf Corsepius wrote:
> Resending, this list is once again swallowing mails.
>
> Joel Sherrill wrote:
>   
>> Matt Rippa wrote:
>>     
>>> Hi all -
>>>
>>> I'm not sure who started managing binaries for the RTEMS
>>> toolchains, but it's really fantastic. I think praise goes to
>>> Ralf Corsepius?
>>>
>>> For Gemini, we're adopting a model to manage RPM spec-files and
>>> a yum repo for all of our observing critical code. I was
>>> wondering if anyone is working on binary releases for rtems-core
>>> and perhaps others such as rtems-addon-packages, and Cexp.
>>> Before I start this effort for our requirements, I was hoping to
>>> hear your thoughts. Maybe it's already in a near term plan?
>>>
>>>   
>>>       
>> Ralf has done some packaging work on this and I really
>> really would like to see us be able to do this for
>> released RTEMS versions.
>>     
> Yes and no.
>
> Yes, I have done some packaging work aiming at this, but this
> unfortunately dropped off the desk for several reasons.
>
> No, this is unlikely to happen for released RTEMS version, because these
> versions have not been prepared to utilize this.
>
>   
I was thinking of making this a 4.10 goal not an additional
requirement on 4.9.  This would be a "new feature" in 4.10
even though bits and pieces have been around but not
finished for a while.
>> Unfortunately, there are some BSP specific clean up
>> issues remaining so every BSP will build against an
>> installed CPU Kit.
>>     
> Correct. This is one detail, I am referring to above.
>
>   
>>  If Ralf can post a work plan for
>> resolving this, I would like to see this in 4.10.
>>     
>
> A work plan would be quite simple:
>
> 1. Start building cpukit rpms from rtems-tarballs.
> I would expect us to be already quite close to be able to do so, however
> the "devil's in the details" - This step definitely isn't intellectually
> challenging, but labor intense and resource consuming ;)
>
>   
Indeed.  That was why I wanted to highlight this
as an activity now with a goal of 4.10 so we would have
time to work on the details.
> Once this step has been performed, I would expect it to be fairly easy
> to back-port to released RTEMS versions.
>
>   
Assuming it doesn't take 100s of BSP specific changes that
 need to be tested on real hardware.  As you say the devil
is in the details.  If it is only a few changes, then it should be
OK.  If it is a lot, then it just will be too much.
> The limiting factor wrt. implementing this at the moment is my personal
> time constraints. For the moment, it will have to remain a "spare-time
> side-task" while working on other topics.
>
>   
I think I was building this way for the tool testing initially
but went back to the old way because I had enough problems
with testing the tools and didn't need to add RTEMS build
issues. 

Can you outline the proper build procedure again?
I will try to leave a build running over the weekend
and post a report Monday or Tuesday.

Given a known procedure and a list of issues to address,
we can work through them.
> 2. Split out cpukit from the RTEMS source tree and convert it into a
> stand-alone package.
>
> The basic idea would be to ship a separate cpukit-tarball and a tarball
> containing the bsps and the testsuites.
>
> However, the details are unclear to me.
>
>   
Me too.  But I do know that until BSPs can be built against
the installed CPU Kit image, the packaging doesn't matter.

I had expected us to do something like gcc where there is
a master full tarball and subset tarballs which (I think) can be
mechanically produced from the full one.  But I really don't know
either.

--joel
> Ralf
>
>
>   


-- 
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