+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?
