PR469 IDE problem, was: Re: Any New 4.6.4 Issues

Ralf Corsepius ralf.corsepius at
Fri Sep 16 08:30:08 UTC 2005

On Fri, 2005-09-16 at 10:08 +0200, Thomas Doerfler (nt) wrote:
> Hash: SHA1
> Hi,
> Chris Johns schrieb:
> > Ralf Corsepius wrote:
> > 
> >>
> >> If his BSP was part of the official sources, we could even hard code
> >> this into the configure script:
> >> RTEMS_BSPOPTS_SET([SOMEOPTION],[angelopc386],[1])
> >> [Some explanation])
> >>
> > 
> > This may not scale well. I have a PC on my desk where the Compact Flash
> > is mapped as a slave on IDE1. Should we add a config for this and open
> > the door to every PC configuration being a hard coded BSP ?
> > 
> > Can the PC BSP be configured from the command line and then built from
> > the command line or does it have to be invoked from the top level RTEMS
> > configure call ?
> > 
> I agree, I think having unique option sets in the BSP code will not be a
> good idea.
Well, these are per-bsp options, so it's your job as the BSP implementor
to design an appropriate set of options/configuration args.

> Is it possible to put these things (as far as it makes sense) into a
> custom file:
> make/custom/pc386_with_secondary_ide_only.cfg
No, never, only over my dead body, only if hell freezes in ;)

These make-file fragments are the number one source of configuration
problems in RTEMS. Their fundamental design flaw is them being
"makefiles", and not configuration files. They are troublesome at build
time, make-time, installation time and are a PITA to maintain.

A better and equally easy approach would be to write a configure script
wrapper, encapsulating "your typical setup".

>From my perspective, for users this doesn't actually make a difference
to using *.cfg-makefile fragments: You edit a file to reflect your

>From a configuration and maintainers' perspective, the eases things a
* The BSP's configure script is the only centralized source of
configuration info, no make file fragments or environment variables
interfering etc.
* It shifts configuration options from make-time to configuration time
(before make-time).
* No plethora of BSP.cfg to maintain. All user BSPs collapse to a
special setup of a base BSP.


More information about the users mailing list