All -
Ralph and I talked today about the logistics of bringing the OpenSHMEM
code to the 1.7 release branch, as it's now a fairly large set of changes
from the trunk. What we propose is to follow the same proceedure we used
when merging in the RTE framework change, which is essentially a staging
How are you going to more effectively transition codes between 1.7 and 1.9
than from internal code to external code? Decisions made by Mellanox
internally should not negatively impact the community code base.
Brian
On 10/28/13 1:48 PM, "Mike Dubman" wrote:
>pgas/shmem on top of OMPI 1.6 eixtst
pgas/shmem on top of OMPI 1.6 eixtsts for ~1year as internal mellanox tree
with customer base and set of applications using shmem* friends.
we are in process of droping shmem* friends and using osh* ones in internal
codes, but for some codes it will take time to transit.
It would help us to maint
What's the advantage of that approach? You're adding legacy baggage to an
unreleased product, which does not seem like good development practice.
Or, put it another way, one of the 1.7 Release Managers can't see a reason
that we should bring shmemcc and friends into 1.7, so convince me.
Brian
On
I would prefer to keep both names for a while and depricate them gradually.
I suggest to release 1st drop with both namings and drop legacy right after
that.
On Mon, Oct 28, 2013 at 8:22 PM, Barrett, Brian W wrote:
> I'm not sure what we gain by having them. It's a new (to us) product;
> let's
I'm not sure what we gain by having them. It's a new (to us) product;
let's not support legacy names.
Brian
On 10/28/13 11:40 AM, "Jeff Squyres (jsquyres)" wrote:
>Ah -- my mistake in the original post: I now see that it installs *both*
>shmemcc and oshcc (and friends). I didn't notice the os
Unfortunately, the entire infrastructure is currently broken. :-(
The values in that file are MCA parameters - the C code just checks to see
which params are set in various places and takes appropriate action.
We planned to do a "reset" to re-enable C/R since ORTE is now completely async,
the M
Ah -- my mistake in the original post: I now see that it installs *both*
shmemcc and oshcc (and friends). I didn't notice the osh* versions in my
initial post.
The question still remains, though -- do we still want these names installed:
-
$ cd $prefix/bin
$ ls -1 shmem*
shmemcc@
shmemfort
Thanks. That's okay. That's why I am looking at it. To get it working.
It is just not clear how the values from ft-enable-cr are supposed to be
used. They are used in the code as if they are variables. They are
defined, however, in a text file (which is not in C). My question is
how are the values
Thanks Brian,
The code in trunk already generates:
oshccoshfort oshmem_info oshrun
On Sat, Oct 26, 2013 at 12:13 AM, Barrett, Brian W wrote:
> i thought I mentioned this before, but the compilers should be oshcc,
> oshCC, and oshfort, with the starter named oshrun, according to Ap
I'm afraid C/R isn't supported in the trunk nor 1.7 release series at this
time. We're looking to restore that support next year as part of the 1.9
release series.
On Oct 28, 2013, at 8:47 AM, Adrian Reber wrote:
> I am trying to compile openmpi (Revision: 29539) from svn
> with '--with-ft=cr
I am trying to compile openmpi (Revision: 29539) from svn
with '--with-ft=cr'. I get a compilation error and I am
lost how to solve it:
../../../../opal/mca/base/mca_base_components_open.c: In function
'open_components':
../../../../opal/mca/base/mca_base_components_open.c:144:9: error:
'mca_ba
12 matches
Mail list logo
