Multilib swamp

[Kenneth Peters]

At 03:02 PM 3/2/2005 +0100, Ralf Corsepius wrote:
>On Wed, 2005-03-02 at 06:36 -0600, Joel Sherrill  wrote:
>
> > I know TIll and I are being non-committal here but the perfect decision
> > varies based upon the code in question, when it is executed. and when it
> > can vary.  Untested or untestable code is obviously bad.  Creating
> > multilib variants is even worse.  Given that this is an initialization
> > issue, I would lean to dynamic checking -- this code ends up under
> > libbsp anyway.
>You don't need dynamic checking, if the code "ends up under libbsp". You
>can add the code to libcpu or to the bsp in both cases and add
>appropriate defines to bspopts.h or to CFLAGS to conditionally enable
>it.
>
>If you feel you need to use the code under cpukit, add appropriate
>definitions ("extern functions" -- API!) to cpukit and implement these
>functions into libcpu or the BSP.
>
>The rule of thumb is: You must not add defines to cpukit/score, unless
>inevitable.
>
>Ralf

Another thing that can sometimes be done is to insert a code construct 
which will produce a compiler or linker error if you are using the wrong 
variant (for instance, this can often be done to verify structure padding 
if necessary). This may not apply to your case (I don't know anything about 
your platform), but if your compiler/assembler has to be told which PPC 
model is in use, maybe they can produce warnings at build time if you do 
something with BAT registers that are unavailable.

Ken Peters