On Sep 21, 2009, at 9:15 AM, Samuel Thibault wrote:

> >Our __hwloc_restrict macro is actually a copy/paste of AC_C_RESTRICT's
> >tinkering.

Ah, wait, no, I'm mistaking with something else in another project.
Looking closer, this definition is mine.


Whew!  :-)

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.).

--
Jeff Squyres
jsquy...@cisco.com


Reply via email to