[Mesa-dev] [PATCH 4/4] autoconf, scons: Move fallback HAVE_* definitions to headers.

[Matt Turner]

On Thu, Apr 2, 2015 at 7:32 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> These were being defined in SCons, but it's not practical -- we actually
> need to include Gallium headers from external source trees, with
> completely disjoint build infrastructure, and it's unsustainable to
> replicate the HAVE_xxx checks or even hard-coded defines across
> everywhere.

To confirm, you're building external sources with gcc? I don't think
these macros are useful for MSVC.

>
> No actual change in behavior for autoconf.
> ---
>  configure.ac         |  2 +-
>  include/c99_compat.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  scons/gallium.py     | 27 ---------------------------
>  src/util/macros.h    |  2 ++
>  4 files changed, 48 insertions(+), 28 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 520cc22..1485bba 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -230,7 +230,7 @@ _SAVE_LDFLAGS="$LDFLAGS"
>  _SAVE_CPPFLAGS="$CPPFLAGS"
>
>  dnl Compiler macros
> -DEFINES=""
> +DEFINES="-DHAVE_AUTOCONF"
>  AC_SUBST([DEFINES])
>  case "$host_os" in
>  linux*|*-gnu*|gnu*)
> diff --git a/include/c99_compat.h b/include/c99_compat.h
> index 4fc91bc..62ccd46 100644
> --- a/include/c99_compat.h
> +++ b/include/c99_compat.h

c99_compat.h doesn't seem like the right location. I know it seems
like a nice place to add this since it's included everywhere, but I
worry that in a few years we're going to be cleaning it up like we've
been doing with compiler.h and friends.

I might make a separate header to define these? Not sure. Since
probably all cases of #ifdef HAVE___* have a fallback, that runs the
risk of never noticing that you weren't including the right header.

> @@ -141,4 +141,49 @@ test_c99_compat_h(const void * restrict a,
>  #endif
>
>
> +
> +/* Fallback definitions, for when these headers are used by build systems which
> + * don't auto-detect these things.*/
> +#ifndef HAVE_AUTOCONF

I'd rather flip this condition around and not modify configure.ac. But
maybe you can't do that because you're not actually building
everything with scons?

I don't know. This seems nuts. I really don't like adding stuff to the
autotools build system like this.

I really don't know how to deal with this. What I'm hearing is that
even the custom scons build system you guys use isn't sufficient for
your own needs. You're not building the external source trees with the
same build system...?

I mean, in all the build system work I've done I've tried to make sure
scons continues working -- doing things like adding these HAVE_*
definitions to it and such. It's kind of frustrating, and it's even
more frustrating when even that isn't sufficient.