Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] last API possible changes
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2009-09-21 09:40:28


Jeff Squyres, le Mon 21 Sep 2009 09:28:04 -0400, a écrit :
> >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.

That's what I meant.

> 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

I wouldn't have copied something that isn't self-contained.

> >> 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?

But then we can't expose restrict in installed headers since we don't
know _whether_ and how it is defined.

> FWIW, no compiler that I've ever tested complains about the following:
>
> #define foo bar
> #define foo bar

Yes.

> Some (all?) compilers *will* warn if the subsequent definitions are
> different, like this:
>
> #define foo bar
> #define foo barbar

Yes.

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

?
That would make applications get a warning just because they are for
instance using at the same time two libraries which both define restrict
to different things.

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

That's why we have both autoheader-generated
hwloc/include/private/config.h.in and manually-written
hwloc/include/hwloc/config.h.in

Samuel