Rtems-core Binaries

[Joel Sherrill]

Ralf,

Is building every CPU with a configuration
like this sufficient to start shaking out the
problems?

 /home/joel/test-gcc/rtems/configure --target=powerpc-rtems4.10 \
  --enable-multilib --enable-ada --enable-posix --enable-networking \
 --enable-maintainer-mode --disable-tests 
--prefix=/home/joel/test-gcc/bsp-install
make -k

It does seem to try to build every bsp.  and by adding -k,
we can see all BSP specific errors.

--joel

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.
>
>   
>> 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 ;)
>
> Once this step has been performed, I would expect it to be fairly easy
> to back-port to released RTEMS versions.
>
> 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.
>
>
> 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.
>
> 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