I don't think our patches will be mutually exclusive. If I understand you correctly, you are trying to make x32 auto-detectable, hence make it work "out of the box". I like the idea and I also tried x32 auto-detection in the past, but it seemed to me that the infrastructure does not support it very well. I also don't think that enough people use x32 to justify putting many working hours into it.
My approach of this patch on the other hand is much more general in nature: I am trying to support any lib<qual>, as defined in [1]. This allows cmake to be used in environments which have more specific requirements. Hence it overwrites the default heuristic, which is usually wrong in such environments. The x32 ABI is just one scenario where you could apply this overwrite. [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s10.html On Sun, Feb 26, 2017 at 6:38 PM, Steven Newbury <st...@snewbury.org.uk> wrote: > On Sun, 2017-02-26 at 16:25 +0000, Steven Newbury wrote: >> On Sun, 2017-02-26 at 16:42 +0100, Christian Schmidbauer wrote: >> > Hallo, >> > >> > I provided a v2 of my previous patch to the ML a few hours back >> > (see >> > [1]), you can give it a try. I was successfully able to build llvm >> > on >> > Gentoo, by adding the following lines to >> > /usr/portage/eclass/cmake-utils.eclass >> > >> > --- aaa/cmake-utils.eclass 2017-02-07 06:44:59.000000000 +0100 >> > +++ bbb/cmake-utils.eclass 2017-02-26 16:37:53.176993623 +0100 >> > @@ -607,6 +607,7 @@ >> > cat > "${common_config}" <<- _EOF_ || die >> > SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate >> > Gentoo >> > package build") >> > SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library >> > path suffix" FORCE) >> > + SET (CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX >> > "${libdir/lib}" CACHE STRING "") >> > SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH >> > "Output >> > directory for libraries") >> > _EOF_ >> > [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo >> > 'SET >> > (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" >> > FORCE)' >> "${common_config}" >> > >> >> Hallo Chris, >> >> I've made some progress with run-time x32 detection in cmake. I'll >> see >> how that goes, if I can't get it working (which I'm testing now) I'll >> use your approach. > > I have to say, the whole idea behind having either 32-bit or 64-bit > library paths determined by the size of a single type, this way seems a > little flawed to me. Linux x32 (Linux ELF x86-64-32) isn't the only > 32-bit userland on 64-bit kernel. MIPS does the same and there's also > ILP32 for aarch64 (ARM64-32). Not to mention any other ABI variants. > > Previous code used CMAKE_INTERNAL_PLATFORM_ABI at least for MIPS, this > just makes much more sense to me, and it's the approach I've used in my > updated x32 cmake patch to determine at run-time if we're using x32- > abi. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
