From: Godmar Back (gback@cs.utah.edu)
Date: Wed Feb 03 1999 - 13:32:12 EST
>
> On Feb 3, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>
> > The test he supplied did this:
>
> > AC_CACHE_CHECK([for uint32],
> > ac_cv_typedef_uint32,
> > [AC_TRY_COMPILE([#include <kernel/OS.h>],
> > [uint32 dummy_ui32;],
> > ac_cv_typedef_uint32=yes, ac_cv_typedef_uint32=no)])
> > if test $ac_cv_typedef_uint32 = yes; then
> > AC_DEFINE(HAVE_UINT32, 1, [Do we have uint32])
> > fi
>
> > And it did that for every single type (total of 8) --- this seemed to
> > like it's unnecessarily clobbering configure.in with something really
> > beos specific (or is there other systems that define "kernel/OS.h"?)
>
> Although kernel/OS.h is BeOS specific, uint8 et al. are not. The
> proper way to handle this is to check for kernel/OS.h, define a macro
> in acinclude.m4 that conditionally includes a bunch of header files
> and checks for a given type, then defines HAVE_THAT_TYPE if
> appropriate, and call the macro once for each type to test.
>
> I'll try to dig the configure.in/acinclude.m4 code I wrote for japhar
> when I had commit privileges in their CVS tree, and I'll port them to
> Kaffe when I find the time for that.
>
Whatever. If you think that's better, do it that way.
If the current way of doing it breaks things, point out what it breaks
and we fix it.
Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:56 EDT