[CMake] Better BlueGene/P and cross-compile support for CMake

[Marcel Loose]

Oops! Forgot to CC to the list.


Hi Tod,

I'll try to answer some of your questions below inline (I've snipped off
parts of your mail). We're also using a BlueGeneP, but not for so many
packages/executables as you probably do.

On Wed, 2010-06-23 at 01:02 -0700, Todd Gamblin wrote:
> Hi,

-- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< --

> I was able to build with either if I just manually specified the
> compilers and linker like this:
> 
> 
> > env CC=gcc C++=g++ LD=ld ./bootstrap --prefix=${CMAKE_HOME}
> 
> 
> > env CC=xlc C++=xlC LD=xlC ./bootstrap --prefix=${CMAKE_HOME}
> 
> 
That is probably the safest way to do it, anyways. You then have full
control over which compiler is used to build your stuff.

> But It would've been nice if I didn't have to do all that.  Is PPC
> Linux not used many other places anymore?  I guess this is a
> sles10/ppc64 environment, so maybe that is throwing the script off.
> 
> 
> 
> 
> 2. The FindMPI module's library search breaks because the the
> cross-compiler name on BlueGene/P contains -l. Specifically, the GNU
> compute node compilers on BlueGene/P are named like this:
> 
> 
> > powerpc-bgp-linux-g++
> 
> 
> And the FindMPI module claims that it can't find the '-inux-g++'
> library, or something similar.  I was able to fix this by modifying
> FindMPI's search to look for -l only when it's followed by a space.
>  This is a little worrisome because I think that is a standard gnu
> naming convention, so other platforms with compilers named blah-linux
> are going to have the same bug.
> 
> 
That is a known bug. I've filed it in the bug tracker
http://www.vtk.org/Bug/view.php?id=9093. I've also uploaded a patch
(take the second one), that fixes that problem.

I didn't have any further problems with FindMPI, though. 
For what it's worth, here are the settings I'm using:

set(BGPCN_C         /usr/bin/gcc)
set(BGPCN_CXX       /usr/bin/g++)
set(BGPCN_ASM      
/bgsys/drivers/ppcfloor/gnu-linux/bin/powerpc-bgp-linux-g++)

set(BGPCN_COMPILE_DEFINITIONS
  -B/bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin
  -DHAVE_BGP
  -DHAVE_BGP_CN
  -DHAVE_FCNP
  -DHAVE_MPI
  -I/bgsys/drivers/ppcfloor/comm/include
  -I/bgsys/drivers/ppcfloor/arch/include)

set(CMAKE_FIND_ROOT_PATH
/bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux)

Note that these BGPCN_* variables are set before the project() statement
and they are used to set the CMAKE_* equivalents. For the assembler, we
use the GCC frontend and the BGP backend, because the latter knows how
to handle double-hummer instructions. 

You also need the following three files:

$ cat CMakeASM-BGPInformation.cmake
set(ASM_DIALECT "-BGP")
set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS S)
set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT
"<CMAKE_ASM${ASM_DIALECT}_COMPILER> <DEFINES> <FLAGS> -c -o <OBJECT>
<SOURCE>")
set(CMAKE_ASM${ASM_DIALECT}_LINK_EXECUTABLE
"<CMAKE_ASM${ASM_DIALECT}_COMPILER> <FLAGS> <LINK_FLAGS> <OBJECTS>  -o
<TARGET> <LINK_LIBRARIES>")
include(CMakeASMInformation)
set(ASM_DIALECT)

$ cat CMakeDetermineASM-BGPCompiler.cmake
set(ASM_DIALECT "-BGP")
set(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT ${CMAKE_ASM_COMPILER})
include(CMakeDetermineASMCompiler)
set(ASM_DIALECT)

$ cat CMakeTestASM-BGPCompiler.cmake
set(ASM_DIALECT "-BGP")
include(CMakeTestASMCompiler)
set(ASM_DIALECT)

Also note that we do NOT set CMAKE_SYSTEM_NAME, because with the above
setup this is not needed, and will even screw up things. I know that
it's a bit hackish, but it needed to be done this way, because we're not
really cross-compiling but merely swapping compiler back-ends.

> 
> 
> 3. Finding system libraries in directories not named 'lib'
> 
> 

-- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< --

I cannot really comment on the issues you mentioned here. Hope you found
my contribution useful.

> Thanks!
> 
You're welcome ;-)

> 
> Todd Gamblin
> Center for Applied Scientific Computing
> Lawrence Livermore National Laboratory

Best regards.

-- 
Marcel Loose
Senior Software Engineer, Computing Group, R&D, Astron, the Netherlands