Re: [Boost-build] [boost] [bbv2][autolink] Re: Naming of 32/64 bit libs

From: John Maddock (john_at_[hidden])
Date: 2006-10-17 11:44:24

Rene Rivera wrote:
> John Maddock wrote:
>> Rene Rivera wrote:
>> Both are do-able in the auto-link code (at least I think they are!)
>
> How detailed can we get? I'm assuming when you think it's possible you
> are perhaps only thinking of 32 vs. 64? In BB the architecture can get
> fairly detailed as far as the CPU. So it would include the address
> model (16, 32, and 64), the CPU architecture (x86, ia64, sparc,
>  etc.), and the CPU instruction set (i386, i486, i586, i686, pentium,
> v7, ultrasparc, power, rios, rm7000, and many others).
>
> Not that we would include all that info. Obviously at minimum we would
> want to limit it to both what is possible to detect at PP time, and
> what is link incompatible. Which is likely to take out at least the
> instruction set distinction.

We can detect the processor family:

_M_ALPHA = alpha
_M_IX86 = x86
_M_IA64 = IA64
_M_MPPC = PowerPC, deprecated.
_M_MRX000 - MIPS, deprecated.
_M_X64 = x86/64Bit

and

_M_IX86_FP = SSE level (x86)

So it looks like only x86, x86/64 and ia64 are still supported and relevent?

>> Suggestions?  Add an archetecture flag in addition to the thread etc
>> tags?
>
> Currently we have:
>
>   <base> <toolset> <threading> <runtime> -$(BOOST_VERSION_TAG)
>
> As the OP suggested it likely makes most sense to add a single tag
> between the toolset and threading as that keeps a somewhat relevance
> sorted order:
>
>   <base> <toolset> <architecture> <threading> <runtime>
> -$(BOOST_VERSION_TAG)
>
> The tag would be: -/address-model/_/cpu/

I would make that -/cpu/_/address-model/ :-)

>> We (still) need a way to test this properly BTW.
>
> OK, could you expand on what the testing problem is?

There isn't any!

I started producing a Jamfile to test bbv2's lib naming (attached: lives in 
libs/config/test/link/test).

It works with VC++, but with Intel and Borland the linker complains that it 
can't find the auto-linked lib.  To fix that we would need the path to the 
library specified on the link command line with -Lpath-to-lib-file.

Do you know of a way to extract the path to the lib target to make this 
work?

Thanks,

John.