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

Reply via email to