Re: CMake and CMAKE_LD_FLAGS

2015-06-18 Thread Alan Burlison
On 15/06/2015 22:59, Colin P. McCabe wrote: I think you are right that CMAKE_LD_FLAGS has never done anything, and setting it was always a mistake. The uses of CMAKE_LD_FLAGS in JNIFlags.cmake are harmless, since the -m32 option is not needed for the linker. However, it's more concerning that

Re: CMake and CMAKE_LD_FLAGS

2015-06-15 Thread Colin P. McCabe
Hi Alan, I think you are right that CMAKE_LD_FLAGS has never done anything, and setting it was always a mistake. The uses of CMAKE_LD_FLAGS in JNIFlags.cmake are harmless, since the -m32 option is not needed for the linker. However, it's more concerning that hadoop-mapreduce-client-nativetask se

Re: CMake and CMAKE_LD_FLAGS

2015-06-04 Thread Alan Burlison
On 03/06/2015 21:23, Alan Burlison wrote: hadoop-common-project/hadoop-common/src/JNIFlags.cmake sets the CMAKE_LD_FLAGS variable to the flags required for the linker. However, despite the name, CMAKE_LD_FLAGS is *not* a valid standard CMake variable Confirmed, I've put nonsense flags in CMAKE

Re: cmake

2012-05-23 Thread Roman Shaposhnik
On Wed, May 23, 2012 at 8:58 AM, Owen O'Malley wrote: > After a quick look at cmake, it seems reasonable. Please use feature tests > rather than OS tests. (By that I mean that if Solaris needs "foobar.h" and > RHEL needs "sys/foobar.h" to get the definition for foobar, the code should > ifdef whet

Re: cmake

2012-05-23 Thread Eli Collins
On Wed, May 23, 2012 at 8:58 AM, Owen O'Malley wrote: > After a quick look at cmake, it seems reasonable. Please use feature tests > rather than OS tests. (By that I mean that if Solaris needs "foobar.h" and > RHEL needs "sys/foobar.h" to get the definition for foobar, the code should > ifdef whet

Re: cmake

2012-05-23 Thread Owen O'Malley
After a quick look at cmake, it seems reasonable. Please use feature tests rather than OS tests. (By that I mean that if Solaris needs "foobar.h" and RHEL needs "sys/foobar.h" to get the definition for foobar, the code should ifdef whether they need sys/foobar.h and not if it is solaris or not.) O

Re: cmake

2012-05-23 Thread Steve Loughran
On 22 May 2012 11:33, Radim Kolar wrote: > i have better experience with scons instead of cmake > mmm, may be better to jump beyond make altogether to the higher levels of nativeish build tools. What would be good is that the output can be parsed by jenkins & have that set up to build and test

Re: cmake

2012-05-22 Thread Matt Foley
+1, especially for support of Win native builds. On Tue, May 22, 2012 at 5:07 AM, Harsh J wrote: > I am +1 with this change as well. CMake is a good choice. My other > favorite project, KDE, uses CMake as well and it has worked great > there ever since 2007. > > On Tue, May 22, 2012 at 8:40 AM,

Re: cmake

2012-05-22 Thread Harsh J
I am +1 with this change as well. CMake is a good choice. My other favorite project, KDE, uses CMake as well and it has worked great there ever since 2007. On Tue, May 22, 2012 at 8:40 AM, Eli Collins wrote: > +1   having a build tool that supports multiple platforms is worth the > dependency. I'

Re: cmake

2012-05-22 Thread Radim Kolar
i have better experience with scons instead of cmake

Re: cmake

2012-05-21 Thread Eli Collins
+1 having a build tool that supports multiple platforms is worth the dependency. I've also had good experiences with cmake. On Mon, May 21, 2012 at 6:00 PM, Colin McCabe wrote: > Hi all, > > We'd like to use CMake instead of autotools to build native (C/C++) code in > Hadoop.  There are a lot