Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Question about scheduler support
From: Martin Siegert (siegert_at_[hidden])
Date: 2014-05-16 17:00:02


+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-bounces_at_[hidden]] on behalf of Ralph Castain [rhc_at_[hidden]]
> 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 <fcannini_at_[hidden]<mailto:fcannini_at_[hidden]>>
> 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?