From: Brian P. <br...@tu...> - 2002-10-30 19:19:21
|
David Dawes wrote: > On Wed, Oct 30, 2002 at 11:53:31AM -0700, Brian Paul wrote: >=20 >>David Dawes wrote: >> >>>On Tue, Oct 29, 2002 at 05:01:51PM +0100, Michel D=E4nzer wrote: >>> >>> >>> >>>>>Conclusion: DoLoadableServer being defined somehow makes XFree86Modu= le=20 >>>>>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 rea= lly >>>>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 th= e >>>case at hand, IHaveModules shouldn't be getting defined in those Imake= files >>>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 obj= ect >>>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 modul= e. >> >>David, which symbol do you recommend that I test in Mesa? I'm currentl= y >>testing for XFree86LOADER to determine if I should include "xf86_ansic.= h" >>vs the usual C headers. >=20 >=20 > 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)'. OK, I'll go with the later. IN_MODULE is a bit ambiguous without a comment to explain. >>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 import= s.[ch] >>files. >=20 > That's a good idea. It should make things cleaner. Yes, a number of people have expressed interest in isolating these things all in one place for the sake of other operating systems and/or embedded situations. -Brian |