Martin Siegert wrote: > Just set LDFLAGS='-Wl,-rpath,/usr/local/xyz/lib64' with autotools. > With cmake? Really complicated.
John Cary wrote: > For cmake, > > -DCMAKE_SHARED_LINKER_FLAGS:STRING=-Wl,-rpath,'$HDF5_SERSH_DIR/lib' > or > -DCMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-rpath,'$HDF5_SERSH_DIR/lib' [Tom] OK, so you verified the "really complicated" comment. It seems clear to me that the OpenMPI developers are not going to switch to Cmake. So why is this discussion continuing? -Tom > > I don't have a dog in this, but I will say that we have found supporting > Windows > to be much easier with cmake. If that is not an issue, then autotools is > is just fine too. We do both and are happy with either. > > Yes, one must build cmake to use it. Does not seem to be a critical > issue to me if one wants to support Windows, as you have to install > something (e.g., cygwin) to use autotools. > > We looked into cmake for openmpi a while ago, but only because we wondered > whether there was much interest in supporting Windows. There wasn't. > > As to compiler support, we build our codes on all of > > Clang, OS X native (which is variants of GNU and Clang), > PGI, Intel, Cray, Microsoft Visual, IBM BlueGene (xl). > > Have not tried Absoft, HP-UX, Oracle Solaris (Linux and Solaris), Tru64. > Only rarely are we seeing the last three OS's anymore. No requests. > But I am confident cmake could do these. > > ..........John > > > > > > > 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
