FTBFS: zedboard BSP with SMP

[Jonathan Brandmeyer]

Yeah, well, the targets of interest to me are only available in the latest
Git, and this bleeding edge is quite a gory place!

So far I've only been using the RSB to build the toolchain itself and not
the kernel.  But I understand what you mean, that in principle the kernel
can be installed to yet another (clean) prefix, so long as the application
Makefile is appropriately addressed.

Thanks,
Jonathan


On Wed, May 6, 2015 at 9:03 PM, Chris Johns <chrisj at rtems.org> wrote:

> On 7/05/2015 8:38 am, Jonathan Brandmeyer wrote:
> > What is the cleanest way of blowing away an old compiled BSP when
> > rebuilding it to avoid this in the future, while retaining the toolchain
> > in the chosen prefix?
>
> There is no clean way provided.
>
> I use 2 different approaches, one for development and the other for
> releases.
>
> Releases are easy and this is what the RSB supports for a release, ie it
> builds the tools and RTEMS kernel for you. RTEMS and the tools are built
> into a single prefix and I base the prefix on the release's version, eg
> /opt/rtems/4.11.0. I use a different prefix for each dot release so I
> can keep the trees clean and can move my applications forwards and back
> if I need to without removing any existing configuration.
>
> For development I keep each part in a separate prefix so the tools might
> be under /opt/rtems/4.11 and the BSPs are under /opt/rtems/bsps/4.11. I
> can then just remove the tree and know I am safe. If I want to keep a
> specific build around I use a different prefix for that BSP and separate
> it out.
>
> If you look at waf configure command in examples-v2 you will see the
> tools path and the kernel path can each be specified and if only the
> tools is provided (I think) it is assumed the kernel is also present
> under that prefix.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150506/64510466/attachment-0002.html>