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.
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, 20
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 happ
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 avai
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/ut
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
