Re: [AD] Small problem with driver removals

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> That's an interesting point. And honestly, one I wouldn't mind thinking 
> about. After all it's the preprocessor that's going to take the hit, and 
> the CPP is generally quite fast compared to the actual 
> compiling/optimizing. It won't have an impact on run-time performance or 
> code size.

No, but there may be a problem with it anyway: I've compiled code that 
explicitly used GFX_DIRECTX (apparently because the author didn't trust 
GFX_AUTODETECT to pick it automatically) that otherwise compiled fine. 
Defining the GFX_DIRECTX driver ID on all platforms would not have cought 
that problem and made the code fail at run time. That is much harder to 
debug (I'd probably just have given up in that case).

> it's not fair to go changing the rules after the fact because we caught 
> a mistake we've been making, because it's simpler to change/add a little 
> text to the docs than to fix the code. An API break is an API break. I 
> think it's reasonable to provide the defines, especially for an 
> environment that's so heavilly customizeable and source compilation is 
> the norm for distributing programs.

Well, in principle I think the docs were at fault for not properly 
documenting that symbols will be undefined if Allegro was compiled without 
that driver (although I'd still consider that expected behavior 
personally). However, I also think you're right and the only proper thing 
we can do about it at this point is to provide the ID's always, but simply 
have the driver fail if it is unavailable.

Evert





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/