Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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