[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RTEMS_BSP definition



Eric Norum wrote:

> I just tried running some programs on my 68040/68360 board.
> Nothing worked!
>
>

[..]

>
>
>
>
> But the include $(RTEMS_CUSTOM) includes
> .../make/custom/gen68360_040.cfg which in turn includes
> .../make/custom/gen68360.cfg.
>
> The problem is that .../make/custom/gen68360.cfg redefines RTEMS_BSP
> to be gen68360!!!!!

>
>
>
> I can see a couple of possible fixes.
>
> 1) Remove the definition of RTEMS_BSP from gen68360.cfg.  There's a
> definition in Makefile.inc for this, so why define it in
> gen68360.cfg?
>
> 2) Move the definition in to the ifeq
> ($(RTEMS_GEN68360_COMPANION_MODE),yes) conditional
>
> Comments?
>
> Joel recommended (1), but also suggested that I check with Ralf as well.
>

I agree with Joel. In general, custom/*.cfg files shouldn't set RTEMS_BSP
(there are some exceptional cases related to aliased BSPs).

This problem is probably the result of some incomplete changes to
custom/*.cfg-files, when Joel and I converted them from a flat
configuration file structure to a deep structure.

The fact that gen68360_040.cfg includes gen68360.cfg should be correct
however. The basic idea behind this is that specializations of one BSP
should include/inherit its "parents" BSP's configuration - This eases
building new BSP by deriving them from others a lot.

AFAIS, similar problems may also exist for other BSPs. The p4xxx family
seems to be a potential candidate and there seems to be an inconsistency in
the solaris variant of the posix-BSP, too.

Ralf

--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
http://www.faw.uni-ulm.de