autoconf HAVE macro conventions
I'm not very familiar with autoconf conventions and was wondering why some config.h values are merely defined and some are explicitly defined to 1. Is there a strong convention to do #ifdef HAVE_FOO instead of #if HAVE_FOO when testing for configure features? For various reasons, the ability to define a macro to 0 or 1 would be useful for the Mac OS X version of config.h — it would let us define certain features in terms of other features without as much conditional logic. Kevin
On 10/30/2009 08:24 PM, Kevin Van Vechten wrote:
I'm not very familiar with autoconf conventions and was wondering why some config.h values are merely defined and some are explicitly defined to 1.
That's a bad decision in configure.ac usually. Just look for occurrences of AC_DEFINE([FOO],,[Comment]) and add a 1 between the two commas.
Is there a strong convention to do #ifdef HAVE_FOO instead of #if HAVE_FOO when testing for configure features? For various reasons, the ability to define a macro to 0 or 1 would be useful for the Mac OS X version of config.h — it would let us define certain features in terms of other features without as much conditional logic.
... that said, why can't config.h be generated for Mac OS X by running configure every time a change to the autoconf source is checked in? There should be no need for conditional logic. Paolo
On Oct 30, 2009, at 12:26 PM, Paolo Bonzini wrote:
On 10/30/2009 08:24 PM, Kevin Van Vechten wrote:
I'm not very familiar with autoconf conventions and was wondering why some config.h values are merely defined and some are explicitly defined to 1.
That's a bad decision in configure.ac usually. Just look for occurrences of AC_DEFINE([FOO],,[Comment]) and add a 1 between the two commas.
Cool.
Is there a strong convention to do #ifdef HAVE_FOO instead of #if HAVE_FOO when testing for configure features? For various reasons, the ability to define a macro to 0 or 1 would be useful for the Mac OS X version of config.h — it would let us define certain features in terms of other features without as much conditional logic.
... that said, why can't config.h be generated for Mac OS X by running configure every time a change to the autoconf source is checked in? There should be no need for conditional logic.
Although autoconf doesn't suit our needs when building libdispatch as a part of Mac OS X for a variety of reasons, we're happy to have autoconf in our source tree to due to its importance on other platforms. Kevin
On Oct 30, 2009, at 12:26 PM, Paolo Bonzini wrote:
On 10/30/2009 08:24 PM, Kevin Van Vechten wrote:
I'm not very familiar with autoconf conventions and was wondering why some config.h values are merely defined and some are explicitly defined to 1.
That's a bad decision in configure.ac usually. Just look for occurrences of AC_DEFINE([FOO],,[Comment]) and add a 1 between the two commas.
Is there a strong convention to do #ifdef HAVE_FOO instead of #if HAVE_FOO when testing for configure features? For various reasons, the ability to define a macro to 0 or 1 would be useful for the Mac OS X version of config.h — it would let us define certain features in terms of other features without as much conditional logic.
... that said, why can't config.h be generated for Mac OS X by running configure every time a change to the autoconf source is checked in? There should be no need for conditional logic.
I think this is the problem Kevin is alluding to: Mac OS X projects usually use the same set of source files for all of the multiple machine architectures that the project is be built for. This can cause problems when a configure-time check doesn't match the target architecture. An example that has come up in the past is configure-time detection of endianness. If configure was run on a PowerPC machine, the generated config.h would indicate that the machine was big-endian: /* Define if the machine architecture is big-endian. */ #define WORDS_BIGENDIAN 1 whereas if it was run on in an Intel machine, the generated config.h would indicate that the machine was little-endian: /* Define if the machine architecture is big-endian. */ /* #undef WORDS_BIGENDIAN */ One possible solution that has been employed in the past is to hand- modify the checked in pre-created config.h to use the (Apple-specific) compiler built-in: /* Define if the machine architecture is big-endian. */ #define WORDS_BIGENDIAN __BIG_ENDIAN__ If the code that uses this #define is written using "#if WORDS_BIGENDIAN", it will work correctly, but if it instead uses "#ifdef WORDS_BIGENDIAN", it will incorrectly treat all architectures as big-endian. Ronnie
Mac OS X projects usually use the same set of source files for all of the multiple machine architectures that the project is be built for. This can cause problems when a configure-time check doesn't match the target architecture. An example that has come up in the past is configure-time detection of endianness. If configure was run on a PowerPC machine, the generated config.h would indicate that the machine was big-endian:
AC_C_BIGENDIAN supports universal binaries. You just have to run ./configure CC='gcc -arch i686 -arch ppc' (or anyway use the appropriate GCC flags). Are there any other cases? Paolo
On Oct 30, 2009, at 1:15 PM, Paolo Bonzini wrote:
Mac OS X projects usually use the same set of source files for all of the multiple machine architectures that the project is be built for. This can cause problems when a configure-time check doesn't match the target architecture. An example that has come up in the past is configure-time detection of endianness. If configure was run on a PowerPC machine, the generated config.h would indicate that the machine was big-endian:
AC_C_BIGENDIAN supports universal binaries. You just have to run
./configure CC='gcc -arch i686 -arch ppc'
(or anyway use the appropriate GCC flags).
Are there any other cases?
Ronnie's example was representative of the reason why I'd like to move toward #if HAVE_FOO tests instead of #ifdef HAVE_FOO, but the reasons why we don't run configure during the build process are separate. Kevin
On Oct 30, 2009, at 1:15 PM, Paolo Bonzini wrote:
Mac OS X projects usually use the same set of source files for all of the multiple machine architectures that the project is be built for. This can cause problems when a configure-time check doesn't match the target architecture. An example that has come up in the past is configure-time detection of endianness. If configure was run on a PowerPC machine, the generated config.h would indicate that the machine was big-endian:
AC_C_BIGENDIAN supports universal binaries. You just have to run
./configure CC='gcc -arch i686 -arch ppc'
(or anyway use the appropriate GCC flags).
Are there any other cases?
What about the SIZEOF_LONG test? Does autoconf do the right thing for '-arch i386 -arch x86_64'? Also, what version of autoconf is required to get the support for AC_C_BIGENDIAN and universal binaries? Ronnie
Are there any other cases?
What about the SIZEOF_LONG test? Does autoconf do the right thing for '-arch i386 -arch x86_64'?
No, those don't work (they just cannot). You can always replace them with things such as AH_VERBATIM([#if defined __SIZEOF_LONG__ #define SIZEOF_LONG __SIZEOF_LONG__ #elif defined __LP64__ #define SIZEOF_LONG 8 #else #define SIZEOF_LONG 4 #endif ]) Hum, should make an Autoconf patch to use __SIZEOF_xyz__ defines. :-)
Also, what version of autoconf is required to get the support for AC_C_BIGENDIAN and universal binaries?
2.62, but it was buggy until 2.63 (2008-09-09). Paolo
On Fri, 30 Oct 2009, Kevin Van Vechten wrote:
I'm not very familiar with autoconf conventions and was wondering why some config.h values are merely defined and some are explicitly defined to 1.
Is there a strong convention to do #ifdef HAVE_FOO instead of #if HAVE_FOO when testing for configure features? For various reasons, the ability to define a macro to 0 or 1 would be useful for the Mac OS X version of config.h — it would let us define certain features in terms of other features without as much conditional logic.
As I understand it, some of this is simply a feature of the way autoconf works: AC_CHECK_DECLS(), used for testing macros, checks conditionally define HAVE_DECL_foo, whereas functional checks, such as AC_CHECK_FUNCS(), used for testing for functions, defines HAVE_foo unconditionally but with a value of 0 or 1. I'd be quite happy to learn about ways to avoid this happening. :-) Robert N M Watson Computer Laboratory University of Cambridge
As I understand it, some of this is simply a feature of the way autoconf works: AC_CHECK_DECLS(), used for testing macros, checks conditionally define HAVE_DECL_foo, whereas functional checks, such as AC_CHECK_FUNCS(), used for testing for functions, defines HAVE_foo unconditionally but with a value of 0 or 1. I'd be quite happy to learn about ways to avoid this happening. :-)
I think Kevin was thinking more of these. --- configure.ac | 16 ++++++++-------- m4/private-extern.m4 | 4 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/configure.ac b/configure.ac index f40700a..19c4d05 100644 --- a/configure.ac +++ b/configure.ac @@ -43,7 +43,7 @@ AC_ARG_ENABLE([legacy-api], AS_IF([test "x$enable_legacy_api" != "xyes"], [use_legacy_api=false - AC_DEFINE(DISPATCH_NO_LEGACY,,[Define to compile out legacy API])], + AC_DEFINE(DISPATCH_NO_LEGACY, 1,[Define to compile out legacy API])], [use_legacy_api=true] ) AM_CONDITIONAL(USE_LEGACY_API, $use_legacy_api) @@ -59,7 +59,7 @@ AC_ARG_ENABLE([libdispatch-init-constructor], ) AS_IF([test "x$enable_libdispatch_init_constructor" != "xno"], - [AC_DEFINE(USE_LIBDISPATCH_INIT_CONSTRUCTOR,, + [AC_DEFINE(USE_LIBDISPATCH_INIT_CONSTRUCTOR, 1, [Define to tag libdispatch_init as a constructor])] ) @@ -72,7 +72,7 @@ AC_ARG_ENABLE([apple-crashreporter-info], ) AS_IF([test "x$enable_apple_crashreporter_info" = "xyes"], - [AC_DEFINE(USE_APPLE_CRASHREPORTER_INFO,, + [AC_DEFINE(USE_APPLE_CRASHREPORTER_INFO, 1, [Define to use Mac OS X crashreporter info])] ) @@ -88,7 +88,7 @@ AC_ARG_ENABLE([apple-tsd-optimizations], ) AS_IF([test "x$enable_apple_tsd_optimizations" = "xyes"], - [AC_DEFINE(USE_APPLE_TSD_OPTIMIZATIONS,, + [AC_DEFINE(USE_APPLE_TSD_OPTIMIZATIONS, 1, [Define to use non-portable pthread TSD optimizations for Mac OS X)])] ) @@ -98,7 +98,7 @@ AC_ARG_ENABLE([apple-semaphore-optimizations], ) AS_IF([test "x$enable_apple_semaphore_optimizations" = "xyes"], - [AC_DEFINE(USE_APPLE_SEMAPHORE_OPTIMIZATIONS,, + [AC_DEFINE(USE_APPLE_SEMAPHORE_OPTIMIZATIONS, 1, [Define to use non-portablesemaphore optimizations for Mac OS X])] ) @@ -139,7 +139,7 @@ AC_CHECK_HEADERS([Availability.h pthread_machdep.h pthread_np.h malloc/malloc.h # of Machisms, including using Mach ports as event sources, etc. # AC_CHECK_HEADER([mach/mach.h], - [AC_DEFINE(HAVE_MACH,,Define if mach is present) + [AC_DEFINE(HAVE_MACH, 1,Define if mach is present) use_mig=true], [use_mig=false] ) @@ -150,7 +150,7 @@ AM_CONDITIONAL(USE_MIG, $use_mig) # in support for pthread work queues. # AC_CHECK_HEADER([pthread_workqueue.h], - [AC_DEFINE(HAVE_PTHREAD_WORKQUEUES,,Define if pthread work queues are present)] + [AC_DEFINE(HAVE_PTHREAD_WORKQUEUES, 1,Define if pthread work queues are present)] ) # @@ -174,7 +174,7 @@ DISPATCH_C_BLOCKS # AC_COMPILE_IFELSE([ AC_LANG_PROGRAM([void __attribute__((__noreturn__)) temp(void) { __builtin_trap(); }], [])], [ - AC_DEFINE(HAVE_NORETURN_BUILTIN_TRAP,,[Define if __builtin_trap marked noreturn]) + AC_DEFINE(HAVE_NORETURN_BUILTIN_TRAP, 1,[Define if __builtin_trap marked noreturn]) ], []) # diff --git a/m4/private-extern.m4 b/m4/private-extern.m4 index f227eb6..a2396e9 100644 --- a/m4/private-extern.m4 +++ b/m4/private-extern.m4 @@ -18,9 +18,9 @@ AC_CACHE_CHECK([for __private_extern__], [dispatch_cv_private_extern=no])]) if test $dispatch_cv_private_extern = yes; then - AC_DEFINE(HAVE_PRIVATE_EXTERN,, Define if __private_extern__ present) + AC_DEFINE(HAVE_PRIVATE_EXTERN, 1, Define if __private_extern__ present) elif test $dispatch_cv_hidden_visibility_attribute = yes; then - AC_DEFINE(HAVE_PRIVATE_EXTERN,, Define if __private_extern__ present) + AC_DEFINE(HAVE_PRIVATE_EXTERN, 1, Define if __private_extern__ present) AC_DEFINE([__private_extern__], [extern __attribute__ ((visibility ("hidden")))], [Define to a replacement for __private_extern]) else -- 1.6.2.5
On Sat, 31 Oct 2009, Paolo Bonzini wrote:
As I understand it, some of this is simply a feature of the way autoconf works: AC_CHECK_DECLS(), used for testing macros, checks conditionally define HAVE_DECL_foo, whereas functional checks, such as AC_CHECK_FUNCS(), used for testing for functions, defines HAVE_foo unconditionally but with a value of 0 or 1. I'd be quite happy to learn about ways to avoid this happening. :-)
I think Kevin was thinking more of these.
I've merged (pretty much) this patch as r83, although I also used defines of '1' in the previous revision, r82, that attempts to move policy for selecting the semaphore implementation into configure.ac from the C source. Robert
On 11/02/2009 12:28 PM, Robert Watson wrote:
I've merged (pretty much) this patch as r83, although I also used defines of '1' in the previous revision, r82, that attempts to move policy for selecting the semaphore implementation into configure.ac from the C source.
r82 is nice. :-) Now that everything is merged, I'll rebase my remaining patches and repost. Paolo
participants (4)
-
Kevin Van Vechten
-
Paolo Bonzini
-
Robert Watson
-
Ronnie Misra