On Wed, Oct 30, 2002 at 11:53:31AM -0700, Brian Paul wrote: >David Dawes wrote: >> On Tue, Oct 29, 2002 at 05:01:51PM +0100, Michel Dänzer wrote: >> >> >>>>Conclusion: DoLoadableServer being defined somehow makes XFree86Module >>>>be defined. >>> >>>I thought it was only defined when DoLoadableServer is defined as YES, >>>but it turns out it's always defined. Is that a bug, or should we really >>>check for XFree86Server or XFree86LOADER (I see the latter used to be >>>checked for before the merge), or should assert.h be #included >>>unconditionally? >> >> >> think it's there to for some driver build requirements. Anyway, in the >> case at hand, IHaveModules shouldn't be getting defined in those Imakefiles >> for a static build. >> >> The XFree86LOADER -> XFree86Module change (and the related Imakefile >> changes) were part of an update for OS/2, where the modules use an object >> format different from the native one. >> >> Maybe using IN_MODULE as a test would be better (but it wouldn't have >> exposed the current problem). That one is only ever supposed to be >> defined when building objects destined to be part of an X server module. > >David, which symbol do you recommend that I test in Mesa? I'm currently >testing for XFree86LOADER to determine if I should include "xf86_ansic.h" >vs the usual C headers.
It needs to be XFree86Module or IN_MODULE. I'd probably go with the latter for Mesa. If that looks too generic namespace-wise, you could make it '#if defined(XFree86LOADER) && defined(IN_MODULE)'. >This is something that I'm trying to clean up in the newest Mesa code. >I.e. all external functions, headers, etc will be wrapped by the imports.[ch] >files. That's a good idea. It should make things cleaner. David ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
