On Fri, 23 Mar 2001, Andreas Beck wrote:
> The target lib needs to be loaded first, because it contains setmode, and
> thus can figure out what libs should be loaded at all after a setmode.
> Moreover it might want to run extra setup code, especially in an extension.
> 
> For now we had solved the case where this leads to a conflict (i.e. where
> target specific stuff overloads stubs) by either explicitly overloading in
> the setmode call after the targets were all loaded, or by using a special
> rendering lib like display-kgi, which will tunnel the commands back to the
> target code.

Hmmm... well the stuff I need to overload right now is actually used
pre-setmode, and is not a mode dependant at all, though I think I 
would not rule out the possibility that there will come a time when 
I'll also want to do mode-dependant sublibs in a few special cases.

> One possibility to solve it would be to always load a default-$targetname
> module by convention at the end of the rendering chain or maybe in a
> suitable place near the end (the target might want to add more fine grained
> overrides, like in: default-X, default-XF86DGAisthere ).
> 
> I think this would be a nice and clean solution which as well doesn't break
> anything.

Well, for my purposes, adding a stubs library to be loaded at the very top
would be what I'm after.  That would mean I'd need yet another at the 
top.  3 seems a bit much... maybe the library should just be loaded
multiple times and be able to keep track of what stage of the loading 
should occur -- e.g. add a flag to the getapi parms that can be
set to init, premode, postmode.  (It's not like ggiGetAPI() is actually
used by the world at large.)  Maybe thats sort of what you were suggesting?

> Comments welcome.

Thanks.

P.S. Isn't it insanely late over there?

--
Brian

Reply via email to