Announcement: Legacy libnetworking will be removed from RTEMS and will be placed in a separate repository
chrisj at rtems.org
Thu Mar 4 23:36:36 UTC 2021
On 5/3/21 4:42 am, Johnson, Andrew N. wrote:
> On Mar 3, 2021, at 6:45 PM, Chris Johns via Core-talk <core-talk at aps.anl.gov
> <mailto:core-talk at aps.anl.gov>> wrote:
>> We should encourage users to add BSP build stacks to the RSB. I remember Andrew
>> Johnson posted on for a Coldfire. We should merge that one.
> That file was trivial to create, it ought to be easy to automate generating it.
If the files are upstream in our repo we can check they build before we cut
> However one drawback is that it always builds the compiler and toolchain as well
> as the BSP, so anyone working on more than one BSP will be wasting cycles if
> they use that. I don’t know if RSB could be taught to not do toolchain builds
> unnecessarily, or if you could provide a different set of recipes that don’t
> have them as a component to be built?
Yes what we currently have does not align nicely to this way of building and I
think we should provide support to make this easier and the builds faster. I do
not think you are alone here and I welcome the feedback.
I think it is important we sort this out. Yes you can build the BSPs as Michael
has shown and these ecosystem tools are designed in layers so you do this but
it would be nice to be able to ask the RSB to build EPCIS m68k, powerpc or arm
BSPs in a single pass. This comes back to the first comment I made, RTEMS would
love to have a current and valid list of BSPs active in EPICS so we can make
sure they build. In time if we can add public hardware test results we will be
in great shape.
> Michael Davidsaver taught me to run commands like this instead to avoid wasting
> cycles when I had already built the toolchain:
>> ../source-builder/sb-set-builder \
>> --host=powerpc-rtems5 --target=powerpc-rtems5 \
>> --prefix=/home/anj/RTEMS-5.1/rtems-5.1 \
>> --with-rtems-bsp=mvme3100 \
>> 5/rtems-kernel 5/rtems-libbsd
> BTW why do both the --host= and --target= options there (equivalent to %defines
> in the .bset file) specify the RTEMS target? That seems weird to me.
The RSB started a long time ago as a personal tool to build the GNU tool chain
for MacOS using RPM spec files. These arguments matched the triplet terms
configure scripts use. The RSB can Candian cross compile (Cxc) tools, for
example building on Linux a Windows compiler for RTEMS and what you have here is
based on how those match up. The RSB internally has a "macro" database and all
the command line parsing ever did was set a macro. A build set (bset) can also
set a macro so the defines are a cheap trick to do this.
More information about the devel