On May 22, 2013, at 10:00 AM, "Barrett, Brian W" <bwba...@sandia.gov> wrote:
>> Hmmm...the issue is that perl usually is included in the distro, but >> python often is not - you have to add that module. This seems to be a key argument, but I'm not sure it's still true. I'm a RHEL guy; I see that RHEL has installed python by default since RHEL4 (i.e., many, many years ago). Are there other Linux distros that really don't install Python by default? This would surprise me. I see python on my OS X Lion, and apparently in every OS X since (at least) Leopard (Tony at Absoft checked for me). I don't know about Python+Solaris, but I don't know if we (OMPI) care, either. >> IIRC, that was the >> rationale for allowing perl. Others (e.g., me) had played with using >> python before, but switched to perl (a) for the prior rationale, and (b) >> to avoid proliferating language requirements. >> >> I happen to like python myself, but believe there is some value in >> avoiding adding yet another language to our list of requirements. > > I (strongly) agree with Ralph. We made a decision (way back in the 1.0 > timeframe) that we would use perl for a scripting language when absolutely > necessary. And even at that, I believe we only require Perl for developer > builds or distribution builds where an assembly file doesn't already exist > for that compiler. I believe that that is still true -- that's one of the reasons I sent around this RFC (because introducing python at end-user "make" time is a Big Change). > I have no problem with the change to generated bindings from a single > configuration file/set of files, a bit of a problem with that happening at > at configure / build time on a release distribution (we don't require > anything other than /bin/sh at configure / build time right now), FWIW: the current Bourne shell scripts that generate the use mpi bindings are pretty... horrible. We have no intention of continuing to use Bourne shell scripts for future code generation. A little more rationale for scripting/generating at "make" time in general: the problem is that Fortran compiler support is literally all over the map; it's really not feasible to maintain a single .F90 file with preprocessor macros to cover all the differences, because some differences require different coding approaches (e.g., inline in a module vs. separate/individual .F90 files -- the contents of these two are quite different). That being said, we *could* pre-generate all possibilities and ship them all in a tarball (i.e., only invoke a generator script at developer/make dist time). Note that that would lead to a bit more complexity, and could lead to even more than 7 copies in the tarball (7 is pretty much the minimum -- and that's with very heavy use of preprocessor macros). Hence, in a perfect world, we could generate at "make" time only exactly what the user's Fortran compiler needed. > and a > strong problem with using Python instead of the Perl that we've previously > agreed we'd use when all other options are unavoidable. I'm asking because: - the contributor (Craig) has been around for years; he has a proven track record of maintaining what he has contributed - the contributor wants to fundamentally advance our Fortran support - the contributor has a strong preference for Python - from my anecdotal evidence, Python is pretty ubiquitous these days (is that wrong?) -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
