This was committed in r21272
Let me know if you have any problems with this commit.
Cheers,
Josh
On May 26, 2009, at 10:00 AM, Jeff Squyres wrote:
Exxxcellent. :-)
On May 26, 2009, at 9:57 AM, Josh Hursey wrote:
As a heads up, this RFC expires today. We discussed it last week
during the t
Exxxcellent. :-)
On May 26, 2009, at 9:57 AM, Josh Hursey wrote:
As a heads up, this RFC expires today. We discussed it last week
during the teleconf and there were no objections.
I updated the HG branch to the current trunk, and, if there are not
objections, I will commit it to the trunk thi
As a heads up, this RFC expires today. We discussed it last week
during the teleconf and there were no objections.
I updated the HG branch to the current trunk, and, if there are not
objections, I will commit it to the trunk this afternoon [target 1.5].
Cheers,
Josh
On May 11, 2009, at 2:3
On May 12, 2009, at 4:37 PM, Josh Hursey wrote:
I updated the branch with the following changes based on discussions
on and off list:
* Change configure option from '--enable-ext=LIST' to '--enable-mpi-
ext[=LIST]'
* If no list is given to '--enable-mpi-ext' then ALL extensions that
can be
I updated the branch with the following changes based on discussions
on and off list:
* Change configure option from '--enable-ext=LIST' to '--enable-mpi-
ext[=LIST]'
* If no list is given to '--enable-mpi-ext' then ALL extensions that
can be built, are built.
* Add "#define OMPI_HAVE
On May 12, 2009, at 9:37 AM, Josh Hursey wrote:
For the same reasons that Jeff mentioned, I think it is probably
better to have a separate mpi-ext.h outside of mpi.h. It just makes
things a bit more explicit for the programmer.
With regard to the #define, should we have one for all extended
int
For the same reasons that Jeff mentioned, I think it is probably
better to have a separate mpi-ext.h outside of mpi.h. It just makes
things a bit more explicit for the programmer.
With regard to the #define, should we have one for all extended
interfaces (i.e., OMPI_HAVE_MPI_EXT) or one for
I *believe* we chose to make it a separate file to drive
the point home to the MPI application developer that these are non-
standard API functions, use at their own risk, yadda yadda yadda.
Maybe it would be worthwhile to have an extra #define that indicates
whether these functions are ava
I like this, however wouldn't it possibly be nice to have a the
mpi-ext.h pulled in by mpi.h when the -enable-ext configure option is
used? That way one would be able to compile and run current tests for
regressions without having to change the code.
--td
Jeff Squyres wrote:
I'm [obviously
I'm [obviously] in favor of this RFC. :-)
On May 11, 2009, at 2:37 PM, Josh Hursey wrote:
What: Infrastructure for MPI Interface Extensions
Why: Allow for experimentation with new interfaces without changing
mpi.h
Where: Temporary Mercurial branch (link below)
http://cgi.cs.indiana.e
10 matches
Mail list logo
