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 10/28/13 1:08 PM, "Mike Dubman" <[email protected]> wrote: >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 ><[email protected]> wrote: > >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)" <[email protected]> >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 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@ >>shmemrun@ >>----- >> >> >>On Oct 28, 2013, at 1:03 PM, Mike Dubman <[email protected]> >> wrote: >> >>> Thanks Brian, >>> The code in trunk already generates: >>> >>> oshcc oshfort oshmem_info oshrun >>> >>> >>> On Sat, Oct 26, 2013 at 12:13 AM, Barrett, Brian W <[email protected]> >>>wrote: >>> i thought I mentioned this before, but the compilers should be oshcc, >>>oshCC, and oshfort, with the starter named oshrun, according to Appendix >>>C of the spec. >>> >>> Brian >>> >>> -- >>> Brian W. Barrett >>> Scalable System Software Group >>> Sandia National Laboratories >>> ________________________________________ >>> From: devel [[email protected]] on behalf of Jeff Squyres >>>(jsquyres) [[email protected]] >>> Sent: Friday, October 25, 2013 3:32 PM >>> To: Open MPI Developers >>> Subject: [EXTERNAL] Re: [OMPI devel] shmem vs. oshmem >>> >>> On Oct 25, 2013, at 12:58 PM, Igor Ivanov <[email protected]> >>>wrote: >>> >>> >> - shmemcc / shmemfort / shmem_info / shmemrun >>> >> --> should these all be "oshmem*" ? >>> >> >>> >> - the examples are hello_shmem* and ring_shmem* >>> >> --> should these all be "*_oshmem*" ? >>> > These examples are not OpenSHMEM specific. >>> >> >>> >> - there are header files named shmem* >>> >> --> I'm guessing the names "shmem.h" and "shmem.fh" are mandated >>> > OpenSHMEM specification says >>> >>> So ya, those names are standardized -- no problem. >>> >>> But shouldn't we be branding everything else as oshmem? Even if the >>>examples are not oshmem-specific. >>> >>> We're shipping oshmem, not shmem, so why not call them oshmem examples >>>[that also happen to be shmem examples] -- rather than shmem examples >>>[that also happen to be oshmem examples]? >>> >>> -- >>> Jeff Squyres >>> [email protected] >>> For corporate legal information go to: >>>http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> devel mailing list >>> [email protected] >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> _______________________________________________ >>> devel mailing list >>> [email protected] >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >>> _______________________________________________ >>> devel mailing list >>> [email protected] >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >>-- >>Jeff Squyres >>[email protected] >>For corporate legal information go to: >>http://www.cisco.com/web/about/doing_business/legal/cri/ >> >>_______________________________________________ >>devel mailing list >>[email protected] >>http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > >-- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > >_______________________________________________ >devel mailing list >[email protected] >http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > > > > -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories
