++1
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
--with-slurm=no --with-loadleveler=no
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
build system.
Gus Correa
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.
Everytime
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
was
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.
Cheers,
Martin
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.
-Nathan
________________________________________
From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain
[r...@open-mpi.org]
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
<fcann...@gmail.com<mailto:fcann...@gmail.com>> wrote:
Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
On May 15, 2014, at 8:00 PM, Fabricio Cannini
<fcann...@gmail.com<mailto:fcann...@gmail.com>>
wrote:
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:
http://fr2.rpmfind.net//linux/RPM/centos/6.5/x86_64/Packages/cmake-2.6.4-5.el6.x86_64.html
http://fr2.rpmfind.net//linux/RPM/dag/redhat/el6/x86_64/extras/cmake-2.8.8-1.el6.rfx.x86_64.html
http://fr2.rpmfind.net//linux/RPM/opensuse/factory/aarch64/aarch64/cmake-3.0.0~rc4-2.1.aarch64.html
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
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
