Re: [AD] allegro-config not working under macosx

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


On 2007-05-27, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On 2007-05-27, Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx> wrote:
> > On 2007-05-27, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > > How's this?
> > 
> > That's nice. Next is a problem compiling the alpy extension. Looks like
> > the 'static auto config' defines in alosxcfg.h are conflicting with
> > those in Python 2.5 headers (error attached).
> > 
> > I undefined manually HAVE_DIRENT_H, HAVE_INTTYPES_H, HAVE_STDINT_H,
> > HAVE_SYS_TIME_H, TIME_WITH_SYS_TIME and HAVE_SYS_STAT_H to make it
> > compile.
> > 
> > I don't remember having this issue with a previous version of Python
> > months ago on a mac, so I don't know if this was introduced by Allegro
> > or Python. To me it looks 'uneducated' to publish these generic autoconf
> > defines in a header visible by end user code, begs for conflicts. OTOH
> > at my previous job we just ignored such warnings hapilly.
> 
> The easiest thing is for us to put prefixes on the HAVE_ macros.
> It should have been done before.  I'll take a look at it.

I've fixed most of the namespace pollution in a local copy.  However I
haven't figured out HAVE_DIRENT_H, HAVE_INTTYPES_H, and some other
"standard" symbols that autoheader generates which we don't even seem to
ask for.  In alosxcfg.h (or whatever) can you try #defining those symbols
to `1' instead of blank and see if gcc still complains?

The other thing we could do is not use autoheader to generate
alunixac.hin, but just keep a manually generated copy there.
Then we could also get rid of the PACKAGE_* pollution that we don't even
use.

Peter




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