On Wed, May 30, 2007 at 11:31:56AM +0200, Stepan Kasal wrote:
> I'm afraid there are some misunderstandings here. I'll try to
> make things more clear.
>
> Let's start with your very first mail:
> Until yesterday, the manual said:
>
> | -- Macro: AC_TYPE_INT8_T
> | If `stdint.h' or `inttypes.h' defines the type `int8_t', define
> | `HAVE_INT8_T'. Otherwise, define `int8_t' to ...
>
> As you can see, if configure had to define `int8_t', then the symbol
> `HAVE_INT8_T' is not defined.
>
> So your implementation was wrong, instead of
> + if test "$ac_cv_c_int$1_t" != no; then
> + AC_DEFINE_UNQUOTED([HAVE_INT$1_T], [1], [Define if int$i_t exists.])
> + fi
>
> you should rather call AC_DEFINE only if "$ac_cv_c_int$1_t" is "yes".
Right - so my intended use of testing HAVE_INT8_T to see whether or
not int8_t could be used was flawed anyway.
[...]
> Consistently, when you followed my sugestion and used:
>
> AC_TYPE_UINT8_T
> AC_TYPE_SIZE_T
> AC_CHECK_TYPES([uint8_t, size_t])
>
> then HAVE_UINT8_T would get defined only if `uint8_t' exists on the
> system, not if a substitute was defined by AC_TYPE_UINT8_T.
>
> AC_CHECK_TYPES([uint8_t]) does not actually perform a second check,
> it uses the findings of AC_TYPE_UINT8_T.
> Observe the output of the configure script:
> checking for uint8_t... no
> checking for size_t... no
> checking for uint8_t... (cached) no
> checking for size_t... (cached) no
>
> (You are right, if AC_CHECK_TYPES([uint8_t]) performed the check for
> the second time, it might say "yes", because the just defined
> `uint8_t' macro would have been found.)
Here I have 2 problems:
- I never see uint8_t (cached), and I think this is because
AC_TYPE_INT8_T uses ac_cv_c_uint8_t, whereas AC_CHECK_TYPES tests
ac_cv_type_uint8_t, yet you seem to see it - I do see it for size_t...
- but it seems good to test again, as I otherwise I don't see the use-case
for AC_TYPE_INT8_T.
For a contrived example, say a system doesn't have int64_t but does have
a 64 bit long long int, I was hoping something like the following would do
the right thing:
AC_TYPE_INT64_T <- finds long long int as suitable for int64_t
AC_CHECK_TYPES([int64_t]) <- sets HAVE_INT64_T, as it is usable given above
? or not ?
#ifdef HAVE_INT64_T
code using int64_t
#else
long winded int32_t alternative
#endif
So in a sense, I don't care whether int64_t is "native", but just
that it can be used. If AC_CHECK_TYPES doesn't notice the int64_t
defined by AC_TYPE64_T, the 32bit alternative would compile despite
the usable long long int alternative. Is that intended? (It seems
that AC_CHECK_TYPES checks again, so all is well as it is from my
point of view, but is that by accident?)
[... good explanation of #define & confdefs.h ...]
>
> Hope you find this mosaic of comments useful,
Yes, thank you!
Patrick
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
