I'll throw in one point: fortran is an optional install on Linux, too. :-)
This is a complex issue, and I'm thinking that the email thread has reached the limit of its usefulness. How about discussing in person at the meeting in a little over a week? I'll add it to the agenda. On May 22, 2013, at 3:17 PM, Ralph Castain <r...@open-mpi.org> wrote: > > 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 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
