The original issue was that OMPI builds support for slurm
and loadlevler by default, and this was not desirable (or desired).
That is a non-issue.
If you don't want slurm and loadleveler support,
just configure OMPI
All other supported schedulers can be dismissed by similar configure
flags, if one is strict about having a slim OMPI installation.
For those who love the minutiae, 'configure --help' will show all
options, including those above,
and I am surprised that this was not noticed first place (and used)
by those complaining of the default support
to slurm and loadleveler on OMPI.
So, why the fuss if the solution is so simple?
I am happy with the way OMPI builds.
For me the main goal is to provide a reliable and flexible MPI build
to support parallel programs, not to fiddle with the build system.
Given the small number
of complaints about the OMPI build system on this list so far
(was there any before this one?),
I would guess most OMPI users also are happy with its build system.
We have GigE, Infiniband, and Torque: OMPI picks them up and
works perfectly with them.
We don't have Open-MX or Knem, but if we had, I would like them to be
discovered by OMPI and used.
As Bert Lance would say:
"If it ain't broke, don't fix it."
But not only it is not broken, it works like a charm.
Why switch to a different tool chain?
Is it wise, safe, widely available on the OMPI installed base,
convenient to the final user?
Quite frankly this is the first time I see so much fuss about OMPI's
On 5/16/2014 3:00 PM, Martin Siegert wrote:
>> +1 even if cmake would make life easier for the developpers, you may
>> want to consider those sysadmins/users who actually need to compile
>> and install the software. And for those cmake is a nightmare.
>> I run into a software package that uses cmake it makes me cringe.
>> gromacs is the perfect example - it has become orders of magnitudes
>> more complicated to compile just because it now uses cmake. I still
>> have not succeeded cross compiling (compiling on a machine with a
>> different processor than the code will later run on) gromacs. This
>> trivial before they switched to cmake.
>> Another example: want to add RPATH to the executables/libraries?
>> Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools.
>> With cmake? Really complicated.
>> Please, just say no.
>> On Fri, May 16, 2014 at 08:33:15PM +0000, Hjelm, Nathan T wrote:
>>> +1 the bootstrapping issue is 50% of the reason I will never use
>>> CMake for any production code.
>>> vygr:~ hjelmn$ type -p cmake
>>> vygr:~ hjelmn$
>>> Nada, zilch, nothing on standard OS X install. I do not want to put
>>> an extra requirement on my users. Nor do I want something as
>>> simple-minded as CMake. autotools works great for me.
>>> From: users [users-bounces_at_[hidden]] on behalf of Ralph Castain
>>> Sent: Friday, May 16, 2014 2:07 PM
>>> To: Open MPI Users
>>> Subject: Re: [OMPI users] Question about scheduler support
>>> On May 16, 2014, at 1:03 PM, Fabricio Cannini
>>> <fcannini_at_[hidden]<mailto:fcannini_at_[hidden]>> wrote:
>>> Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
>>> On May 15, 2014, at 8:00 PM, Fabricio Cannini
>>> Nobody is disagreeing that one could find a way to make CMake
>>> work - all we are saying is that (a) CMake has issues too, just
>>> like autotools, and (b) we have yet to see a compelling reason to
>>> undertake the transition...which would have to be a *very*
>>> compelling one.
>>> I was simply agreeing with Maxime about why it could work. ;)
>>> But if you and the other devels are fine with it, i'm fine too.
>>> FWIW, simply for my own curiosity's sake, if someone could confirm
>>> deny whether cmake:
>>> 1. Supports the following compiler suites: GNU (that's a given, I
>>> assume), Clang, OS X native (which is variants of GNU and Clang),
>>> Absoft, PGI, Intel, Cray, HP-UX, Oracle Solaris (Linux and Solaris),
>>> Tru64, Microsoft Visual, IBM BlueGene (I think that's gcc, but am
>>> not entirely sure). (some of these matter mainly to hwloc, not
>>> necessarily OMPI)
>>> Not 100% confirmed, but this is good evidence that cmake does indeed
>>> supports all these suites. See the file list:
>>> 2. Bootstrap a tarball such that an end user does not need to have
>>> cmake installed.
>>> What do you mean by 'bootstrapping a tarball' ?
>>> If someone doesn't have cmake installed and downloads a tarball that
>>> was built from a CMake-based project, can they configure/build that
>>> tarball? Or do they have to install cmake first?
>> users mailing list
> users mailing list