> Note btw that the autoconf license makes an exception for code output
> from autoconf scripts, the GPL doesn't apply to them, there is
> unlimited permission to copy, distribute, and modify it.
>

Yes, but that doesn't include the raw m4 that is included in the AC
source. IANAL, but my understanding is that if you copy the raw m4,
that's taint. If you copied the raw output (e.g., copied the relevant
sh script portions from a generated "configure" script), then you'd be
ok. But that doesn't seem like a safe thing to do, given that various
m4 definitions that are contained in that "configure" script may or
may not remain compatible with future versions of the autotools (e.g.,
mixing that sh code with sh code generated from future versions of the
autotools may or may not work).

But thankfully, this issue is moot. :-)

> > Would it ever be sane to use one value of restrict in hwloc and a
> > different value in an upper-level application?
>
> That's not a problem since it's just an optimization & validity
> checking
> qualifier.
>

So it should be ok to use AC_C_RESTRICT then, right?

FWIW, no compiler that I've ever tested complains about the following:

#define foo bar
#define foo bar

Some (all?) compilers *will* warn if the subsequent definitions are
different, like this:

#define foo bar
#define foo barbar

So I'd call it a "feature" if hwloc defines "restrict" to one thing
and then some other header file defines it to another. :-)

But then again, Autoconf has a *very strict* policy that generated
config.h files are supposed to be private to the application that it
is building. OMPI, for example, does *not* have mpi.h include our
generated config.h. Instead, our mpi.h has a small number of things
set from configure that are required (e.g., size of bool, etc.).