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
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
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
On 22 May 2012 11:33, Radim Kolar h...@filez.com 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
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.)
On a
On Wed, May 23, 2012 at 8:58 AM, Owen O'Malley omal...@apache.org 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
On Wed, May 23, 2012 at 8:58 AM, Owen O'Malley omal...@apache.org 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
i have better experience with scons instead of cmake
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 e...@cloudera.com wrote:
+1 having a build tool that supports multiple platforms is worth the
+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 cmcc...@alumni.cmu.edu wrote:
Hi all,
We'd like to use CMake instead of autotools to build native (C/C++) code in
10 matches
Mail list logo