David Dawes wrote:
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)'.
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 imports.[ch]
files.
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
-------------------------------------------------------
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
