Re: [OMPI devel] Abstraction violation!

2017-06-23 Thread Jeff Squyres (jsquyres)
FWIW: mpi.h is created at the end of configure (it's an AC_CONFIG_HEADERS file).


> On Jun 22, 2017, at 9:37 PM, Barrett, Brian via devel 
>  wrote:
> 
> Thanks, Nathan.
> 
> There’s no mpi.h available on the PR builder hosts, so something works out.  
> Haven’t thought through that path, however.
> 
> Brian
> 
>> On Jun 22, 2017, at 6:04 PM, Nathan Hjelm  wrote:
>> 
>> I have a fix I am working on. Will open a PR tomorrow morning.
>> 
>> -Nathan
>> 
>>> On Jun 22, 2017, at 6:11 PM, r...@open-mpi.org wrote:
>>> 
>>> Here’s something even weirder. You cannot build that file unless mpi.h 
>>> already exists, which it won’t until you build the MPI layer. So apparently 
>>> what is happening is that we somehow pickup a pre-existing version of mpi.h 
>>> and use that to build the file?
>>> 
>>> Checking around, I find that all my available machines have an mpi.h 
>>> somewhere in the default path because we always install _something_. I 
>>> wonder if our master would fail in a distro that didn’t have an MPI 
>>> installed...
>>> 
 On Jun 22, 2017, at 5:02 PM, r...@open-mpi.org wrote:
 
 It apparently did come in that way. We just never test -no-ompi and so it 
 wasn’t discovered until a downstream project tried to update. Then...boom.
 
 
> On Jun 22, 2017, at 4:07 PM, Barrett, Brian via devel 
>  wrote:
> 
> I’m confused; looking at history, there’s never been a time when 
> opal/util/info.c hasn’t included mpi.h.  That seems odd, but so does info 
> being in opal.
> 
> Brian
> 
>> On Jun 22, 2017, at 3:46 PM, r...@open-mpi.org wrote:
>> 
>> I don’t understand what someone was thinking, but you CANNOT #include 
>> “mpi.h” in opal/util/info.c. It has broken pretty much every downstream 
>> project.
>> 
>> Please fix this!
>> Ralph
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@lists.open-mpi.org
 https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>>> 
>>> ___
>>> devel mailing list
>>> devel@lists.open-mpi.org
>>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel


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

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Abstraction violation!

2017-06-22 Thread Barrett, Brian via devel
Thanks, Nathan.

There’s no mpi.h available on the PR builder hosts, so something works out.  
Haven’t thought through that path, however.

Brian

> On Jun 22, 2017, at 6:04 PM, Nathan Hjelm  wrote:
> 
> I have a fix I am working on. Will open a PR tomorrow morning.
> 
> -Nathan
> 
>> On Jun 22, 2017, at 6:11 PM, r...@open-mpi.org wrote:
>> 
>> Here’s something even weirder. You cannot build that file unless mpi.h 
>> already exists, which it won’t until you build the MPI layer. So apparently 
>> what is happening is that we somehow pickup a pre-existing version of mpi.h 
>> and use that to build the file?
>> 
>> Checking around, I find that all my available machines have an mpi.h 
>> somewhere in the default path because we always install _something_. I 
>> wonder if our master would fail in a distro that didn’t have an MPI 
>> installed...
>> 
>>> On Jun 22, 2017, at 5:02 PM, r...@open-mpi.org wrote:
>>> 
>>> It apparently did come in that way. We just never test -no-ompi and so it 
>>> wasn’t discovered until a downstream project tried to update. Then...boom.
>>> 
>>> 
 On Jun 22, 2017, at 4:07 PM, Barrett, Brian via devel 
  wrote:
 
 I’m confused; looking at history, there’s never been a time when 
 opal/util/info.c hasn’t included mpi.h.  That seems odd, but so does info 
 being in opal.
 
 Brian
 
> On Jun 22, 2017, at 3:46 PM, r...@open-mpi.org wrote:
> 
> I don’t understand what someone was thinking, but you CANNOT #include 
> “mpi.h” in opal/util/info.c. It has broken pretty much every downstream 
> project.
> 
> Please fix this!
> Ralph
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@lists.open-mpi.org
 https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>>> 
>>> ___
>>> devel mailing list
>>> devel@lists.open-mpi.org
>>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Abstraction violation!

2017-06-22 Thread Nathan Hjelm
I have a fix I am working on. Will open a PR tomorrow morning.

-Nathan

> On Jun 22, 2017, at 6:11 PM, r...@open-mpi.org wrote:
> 
> Here’s something even weirder. You cannot build that file unless mpi.h 
> already exists, which it won’t until you build the MPI layer. So apparently 
> what is happening is that we somehow pickup a pre-existing version of mpi.h 
> and use that to build the file?
> 
> Checking around, I find that all my available machines have an mpi.h 
> somewhere in the default path because we always install _something_. I wonder 
> if our master would fail in a distro that didn’t have an MPI installed...
> 
>> On Jun 22, 2017, at 5:02 PM, r...@open-mpi.org wrote:
>> 
>> It apparently did come in that way. We just never test -no-ompi and so it 
>> wasn’t discovered until a downstream project tried to update. Then...boom.
>> 
>> 
>>> On Jun 22, 2017, at 4:07 PM, Barrett, Brian via devel 
>>>  wrote:
>>> 
>>> I’m confused; looking at history, there’s never been a time when 
>>> opal/util/info.c hasn’t included mpi.h.  That seems odd, but so does info 
>>> being in opal.
>>> 
>>> Brian
>>> 
 On Jun 22, 2017, at 3:46 PM, r...@open-mpi.org wrote:
 
 I don’t understand what someone was thinking, but you CANNOT #include 
 “mpi.h” in opal/util/info.c. It has broken pretty much every downstream 
 project.
 
 Please fix this!
 Ralph
 
 ___
 devel mailing list
 devel@lists.open-mpi.org
 https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>>> 
>>> ___
>>> devel mailing list
>>> devel@lists.open-mpi.org
>>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Abstraction violation!

2017-06-22 Thread r...@open-mpi.org
Here’s something even weirder. You cannot build that file unless mpi.h already 
exists, which it won’t until you build the MPI layer. So apparently what is 
happening is that we somehow pickup a pre-existing version of mpi.h and use 
that to build the file?

Checking around, I find that all my available machines have an mpi.h somewhere 
in the default path because we always install _something_. I wonder if our 
master would fail in a distro that didn’t have an MPI installed...

> On Jun 22, 2017, at 5:02 PM, r...@open-mpi.org wrote:
> 
> It apparently did come in that way. We just never test -no-ompi and so it 
> wasn’t discovered until a downstream project tried to update. Then...boom.
> 
> 
>> On Jun 22, 2017, at 4:07 PM, Barrett, Brian via devel 
>>  wrote:
>> 
>> I’m confused; looking at history, there’s never been a time when 
>> opal/util/info.c hasn’t included mpi.h.  That seems odd, but so does info 
>> being in opal.
>> 
>> Brian
>> 
>>> On Jun 22, 2017, at 3:46 PM, r...@open-mpi.org wrote:
>>> 
>>> I don’t understand what someone was thinking, but you CANNOT #include 
>>> “mpi.h” in opal/util/info.c. It has broken pretty much every downstream 
>>> project.
>>> 
>>> Please fix this!
>>> Ralph
>>> 
>>> ___
>>> devel mailing list
>>> devel@lists.open-mpi.org
>>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>> 
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Abstraction violation!

2017-06-22 Thread Barrett, Brian via devel
I’m confused; looking at history, there’s never been a time when 
opal/util/info.c hasn’t included mpi.h.  That seems odd, but so does info being 
in opal.

Brian

> On Jun 22, 2017, at 3:46 PM, r...@open-mpi.org wrote:
> 
> I don’t understand what someone was thinking, but you CANNOT #include “mpi.h” 
> in opal/util/info.c. It has broken pretty much every downstream project.
> 
> Please fix this!
> Ralph
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel