> -----Original Message-----
> From: lam-bounces_at_[hidden]
> [mailto:lam-bounces_at_[hidden]] On Behalf Of Jeff Squyres
> Sent: Wednesday, November 17, 2004 7:00 PM
> To: General LAM/MPI mailing list
> Subject: LAM: Poll for LAM users
>
> LAM users --
>
> If you could indulge me for a minute, I'd like to take a poll of all
> you "regular users" out there. As you know, we're working heavily on
> Open MPI (http://www.open-mpi.org/). We anticipate a first stable
> release in 1Q 2005.
>
> SHORT VERSION:
> --------------
>
> 1. If Open MPI uses a build system that requires extra tools (such as
> cmake or jam or ...) to be installed in order to be built
> from source,
> would this be a deterrent to you installing Open MPI from a source
> tarball?
>
> 2. If you answered yes to #1, what kind of system will you
> want to use
> Open MPI on? I.e., what [specific] flavor of system (architecture,
> operating system and version, etc.) would we need to provide a binary
> version of Open MPI for you to install?
>
>
> LONGER VERSION:
> ---------------
>
> One of the LAM technologies that was ported to Open MPI was the
> configure/build system. It relies heavily upon GNU Autoconf,
> Automake,
> and Libtool. It's been improved quite a bit from the
> original LAM code
> but is essentially the same essence. The major advantage of this
> system is that it is trivial for a user to install -- you
> untar it and
> then run "./configure ... ; make all install". Users do not need any
> additional tools to be installed (aside from "make" and a set of
> compilers, which most users already have).
>
> However, it still has a lot of shortcomings (at least from a
> developer's perspective). One big drawback: it's slow. It
> takes quite
> a long time to compile Open MPI (and LAM). Users don't
> generally care
> about this (right?) because they only do it once, but it does cost a
> lot of lost developer time. In short: we're interested in making the
> configure/build system better, stronger, and have fewer carbs.
>
> As such, we're investigating other build systems, such as cmake and
> jam. These are fine systems, but they have one critical difference
> from AC/AM/LT: users who want to build and install Open MPI will have
> to have cmake/jam/whatever installed. Specifically, before you can
> build Open MPI from source, you would need to download and install
> cmake/jam/whatever.
>
> The debate is raging between the Open MPI developers :-), so
> I thought
> I'd ask real users what you thought. Would it be a problem
> for you to
> install some secondary tool to build Open MPI? And if so,
> what systems
> would you need binaries for?
>
> Keep in mind -- none of this has been decided yet. We may go with
> cmake/jam/whatever, or we may stay with AM/AM/LT. Indeed, if people
> ask for binaries for too many systems, it's questionable as
> to whether
> we could actually provide them all, anyway. The point here is that I
> want to find out what you want/need. Specific user requests
> will help
> us make a decision balanced between your input and developer needs.
>
> Many thanks!
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
Answer to question 1: No, it would not be a deterrent.
I recommend SCons (http://www.scons.org). While not as mature as the
Autotools, the authors intend it to be the cross-platform Autotools
successor. Today, SCons is at version 0.96.1 and has a very active
developer community.
SCons is a Python application, and therefore has (only) one dependency -
Python 1.5.2. Given that, the SCons install is trivial and quick.
It appears to be very reliable - one of its stated requirements is to
give priority to correct builds. I can attest to this, and also to a
speedup in my builds, compared to a previous Autotools infrastructure.
Its cross-platform ability can play nicely into Open MPI's future; I
believe Dave Topp (this list) expressed some interest in a win32 Open
MPI. A native win32 build system for Open MPI would be one important
step in that direction.
Also, since it is Python, it is potentially one less syntax to learn.
Regards,
Vince Virgilio
************************************
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Industries, Inc. The recipient should check this e-mail and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this e-mail.
************************************
|
