[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Wed, 30 Sep 1998 09:59:29 +0200
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: 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
> 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
> 2) Move the definition in to the ifeq
> ($(RTEMS_GEN68360_COMPANION_MODE),yes) conditional
> 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.
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