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 <jjhur...@open-mpi.org> 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) > <jsquy...@cisco.com> wrote: > 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/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > -- > Joshua Hursey > Assistant Professor of Computer Science > University of Wisconsin-La Crosse > http://cs.uwlax.edu/~jjhursey _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
