On May 22, 2013, at 11:51 AM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> Let me jump in here with a different perspective. > First, for those who don't know me: > + I am NOT an OMPI developer > + I am NOT an MPI application author either > + I am a developer of "competing" HPC communications software (GASNet) > + I contribute to OMPI mainly by building release candidates on my > menagerie of test systems > + I less frequently contribute bug reports and patches (and opinions like > this one) > > As a developer myself, I agree that the maintainability problem that Jeff and > Craig are trying to address is an important one. I think we all agree there > > I understand the concerns that Ralph has expressed and Brian has echoed, but > I do not fully agree. > > I do agree that *if* one picks a scripting language for build-time tasks > (configure and/or make), the there should really be only one unless there is > a really good motivation for more. But if I understood, the bigger issue > than perl-vs-python is that perl has so far only be required for folks who > need to autogen but not for users who just build from a tarball. I believe there is a tiny amount of perl in the configure/make portion of the build system, but it is very small - perl use is mostly confined to autogen.pl > > In my opinion any "user" who is going to build an MPI implementation should > be capable of installing the reasonable "build dependencies", whether it be > python 2.x, python 3.x, perl or even tcl. It is not like one is asking for > smalltalk or common lisp. True, but many of our users build their own versions of OMPI (as opposed to what is provided by the sys admin), and they often don't have the ability/expertise to install languages. > Additionally, as a "build dependency" the requirement applies only to the > OMPI-build host, not to the host(s) used to build the MPI applications, and > NOT to the compute nodes. Also true > > For the user building sources via RPM or APT packaging for Linux, Fink for > MacOS, or ports/packages for BSDs there are already mechanisms for expressing > build dependencies in those respective systems. Everything is just automatic > for those users. Yep > > Since OMPI already ships all the generated atomics variants in the tarball, > there is precedence in support of the alternative of per-generating all the > Fortran wrapper variants. That does NOT address Brian's strong objection to > adding a new language dependency, but moves the language dependency from the > end-user to the developer, and hopefully only to those developers who modify > the Fortran bindings. I suspect there is less objection to adding a language dependency to the tarball generator - the objections expressed so far were about adding python to the actual configure/compile stages. Users who build their own versions mostly download tarballs, so pushing the Fortran generator into the tarball creation phase would be less of a problem. > > Just my USD 0.02, Always appreciated! > -Paul > > > > > On Wed, May 22, 2013 at 10:47 AM, Barrett, Brian W <bwba...@sandia.gov> wrote: > On 5/22/13 9:35 AM, "Ralph Castain" <r...@open-mpi.org> wrote: > > >* this isn't about Craig and his abilities - this is a more general > >requirements discussion. I personally wouldn't change my comments if it > >was Jeff or Brian making the request - the issue remains the same. > >Introducing another language requirement on the > > user-level build isn't a minor issue. Just because someone knows a > >language seems a weak argument - I had to learn perl to work on the build > >system too. The differences aren't that huge, and the barrier isn't that > >high. > > What Ralph said. My objections are largely to introducing another > language dependency (we should strive to keep these as small in number as > possible). As I said, I'm strongly against using Python in the build > system (unless we replace all Perl with Python, which I doubt anyone wants > to deal with). I have a slight preference for not using non-Bourne Shell > things in the configure / make stages, but that's not anywhere near as > strong as the dislike of adding new languages to support in the build > system. > > Brian > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
