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

[Ralf Corsepius]

On Mon, 2005-09-19 at 15:23 +0200, Thomas Doerfler (nt) wrote:

> >> Some BSPs have variables in the linkcmds which can be overridden at link
> >> time.  It is often used for setting RamSize.  Would this be a good
> >> candidate for this technique?
> 
> Hm, Joel, I don't think so. Reasons:
> 
> 1. The preprocessor #define I have introduced modifies the content and
> the size of a IDE configuration data structure at compile time. With
> your trick I can only think of a solution that would modify the
> structure at runtime, which is a bit more complicated.
> 
> 2. Ralf already objected to the idea to have a different BSP for
Did I? I simply think this is a configuration issue, and not a
completely different BSP. Of cause deriving a BSP is always possible and
might be the easiest solution when deriving a "product", but this isn't
in RTEMS general interest, because we should strive for flexibility and
universality/generality of BSPs.

> Angelo's PC104 board only because it has a different IDE configuration,
> and I fully agree with him.


> 3. Maybe this configuration item will propagate the possibility of
> configure time options a bit more, I think it is quite an elegant way to
> handle options for the RTEMS build process, and at least for me it was new.
>
> I think specifying a special IDE configuration during the "configure"
> run is quite an elegant way to overcome this problem. Each user still
> has the possibilitiy to supply a user-defined "ide_cfg.c" file with a
> special configuration, which is quite similar to your proposal (in this
> case, a BSP library module "ide_cfg.o" will be overridden from a user
> supplied object module), but in most cases the standard ide_cfg.c will do.
> 
> What do you (and all the other users) think?
Let put me put it this way:

I think you are scratching at well-known open weaknesses of :
1. run-time vs. link-time vs. compile-time configuration 
2. static vs. dynamic configuration.

ATM, we don't have much of a systematic approach to address these
issues, but potentially conflicting configuration mechanisms (cpuopts.h,
bspopts.h, confdefs.h, command-line defines (*.cfg), linkcmds,
bsp_specs, make-exe).

Ralf