[CMake] non default architecture builds

[Bill Hoffman]

Mathias Froehlich wrote:
> On Monday 09 July 2007 14:34, Alexander Neundorf wrote:
>   
>> On Monday 09 July 2007 08:10, Mathias Froehlich wrote:
>>     
>>> Hi,
>>>
>>> I need to do no default binary type builds with a cmake based build
>>> system (OpenSceneGraph's cmake build system).
>>> With non default binary type, I am talking about 64 bit builds on hp-ux
>>> or sparc solaris for example.
>>> On hp-ux I have 64 bit libs in .../lib/pa20_64 or on sparc solaris they
>>> are located in .../lib/sparcv9 instead of the usual .../lib directory.
>>>
>>> The first problem that bites me is the FindOpenGL.cmake module.
>>> On hp-ux it will find the /opt/graphics/lib/libGL.sl hppa1.1 32 bit
>>> library (note that the 64 bit hppa2.0 library is available
>>> in /opt/graphics/lib/pa20_64/libGL.sl). My object files are compiled with
>>> CMAKE_CFLAGS='+DA2.0 ...' which will tell the compiler that it should
>>> build hppa2.0 64 bit objects.
>>>
>>> At link time the cmake based gnu makefiles will try to glue the 64 bit
>>> objects to the 32 bit libGL. Obviously this will not work.
>>>
>>> Now my question:
>>> How can I make cmake look into the lib/pa20_64 or lib/sparcv9 directory
>>> instead of the plain lib directory?
>>>       
>> So the problem is that it picks up not the libraries you want, because they
>> are in a special directory ? Everything else (include dirs etc.) is correct
>> ?
>>
>> You could set the CMAKE_LIBRARY_PATH cmake/environment variable to point
>> the lib/pa20_64 and lib/sparcv9 directories to get it working.
>>     
>
> Ok, thanks, that will probably solve my short term problem.
>
> But wouldn't it be better if cmake knows about such path extensions?
> It already knows about the change from lib to lib64 for EMT64 binaries on 
> linux.
>
> Wouldn't it be better to generalize that abi dependent library directory name?
>
> gcc for example knows that multilib direcectory that is relative to the 
> library directory. For
> EMT64 linux:  <libdir>/../lib64
> 64 bit sparc:   <libdir>/sparcv9
> hp-ux pa risc 64 bit: <libdir>/pa20_64
> hp-ux ia64 bit: <libdir>/hpux64
> irix 64 bit: <libdir>/../lib64
> ....
>
> Wouldn't it make sense to generalize the hard coded 64 bit linux library 
> search path to something configurable.
> Say we invent a new CMAKE_MULTILIB_PATH variable that can be set.
> For EMT64 linux this would replace the hardcoded c++ code and would read:
> CMAKE_MULTILIB_PATH=../lib64:.
> For that pa20_64 hp-ux stuff this would then read:
> CMAKE_MULTILIB_PATH=pa20_64
>   
Sounds like a good candidate for something that should be in the 
platform files.   Can you create a feature
request?

-Bill