Good question - I haven't gone that far into it either.

As for Jeff's other questions:

* python packaging. I don't know if/where it comes standard. I typically add it to CentOS when I install, but that is always a selection option. I don't know if it has some basic level of python support included as I've never checked - I always select the python lib options.

* I have no issue with scripting the Fortran support at build time, but I still think we should stick to some limit on language requirements. Not a rock-hard position, but a preference. Even if python is distributed now, you still have the version level issues we see with the configure stuff. We've managed to keep that out of the user-level build code, but this introduces it there. In fairness, I imagine we also have that with perl, though I think there is less issue with backward compatibility in that language? At least, we've never hit an issue.

* 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.

Like I said, I don't have a rock-hard position on this - just question the rationale provided so far.

On May 22, 2013, at 9:18 AM, Josh Hursey <> wrote:

Is this Python 2.x or 3.x? I ask because they are not 100% compatible due to changes in the language syntax. Meaning not all 2.x compilant Python programs work with a 3.x interpreter. IIRC there is a way to write a 2.x compliant Python program so that it is also 3.x compliant, but my Python knowledge does not go deep enough to tell you exactly how to do that.

If we are going to require Python in the build path, we should be specific on this point and check in the configure script.

-- Josh 

On Wed, May 22, 2013 at 11:03 AM, Jeff Squyres (jsquyres) <> wrote:
On May 22, 2013, at 10:00 AM, "Barrett, Brian W" <> 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
For corporate legal information go to:

devel mailing list

Joshua Hursey
Assistant Professor of Computer Science
University of Wisconsin-La Crosse _______________________________________________
devel mailing list