Boost logo

Boost-Build :

Subject: Re: [Boost-build] 4-way fat binaries
From: Ian Emmons (iemmons_at_[hidden])
Date: 2008-12-08 12:02:42

On Dec 8, 2008, at 11:14 AM, Vladimir Prus wrote:

> On Sunday 07 December 2008 19:16:30 Michael Jackson wrote:
>> On Dec 7, 2008, at 8:15 AM, Vladimir Prus wrote:
>>> On Sunday 07 December 2008 15:35:24 Michael Jackson wrote:
>>>> On Dec 7, 2008, at 3:29 AM, Vladimir Prus wrote:
>>>>> [Mat, Rene, I CC you as the resident OSX experts here]
>>>>> I've checked in the patch from
>>>>> that implements 4-way fat binaries on OSX. The command line syntax
>>>>> is:
>>>>> bjam architecture=combined address-model=32_64
>>>>> Because I go and document this, anybody has comments about the
>>>>> naming? For one
>>>>> thing, should we use
>>>>> bjam architecture=x86_ppc address-model=32_64
>>>>> instead, as 'combined' seems somewhat vague. (Of course, we'll
>>>>> keep
>>>>> 'combined' for
>>>>> backward compatibility)
>>>>> Thanks,
>>>>> Volodya
>>>>> --
>>>>> Vladimir Prus
>>>>> Boost.Build V2:
>>>> As and OS X Developer, the first time I tried to build boost as a
>>>> Universal Binary it took me longer than it should have because
>>>> didn't use the naming conventions that Apple had laid
>>>> out,
>>>> "Universal" or "Fat Binary". "Combined" just is not recognized on
>>>> OS X
>>>> as a proper "word" that describes Universal binary.
>>>> Having said that, I understand that this needs to be "cross-
>>>> platform" so my personal vote is for arch=i386,x86_64,ppc,ppc64
>>>> style.
>>>> It covers _all_ the combinations.
>>> This might be good, but it's fairly incompatible with how things
>>> works
>>> on other platforms Boost.Build support and would make things
>>> slightly
>>> better on OSX by default, but confusing for cross-platform
>>> development.
>>> Besides, if you want to separately build x86 32 bit and x86 64 bit
>>> binaries,
>>> how do you specify that?
>>>> Just as a corner case of your first suggestion, what if I want to
>>>> build a 32bit i386 and a 64 bit PPC. What would the correct
>>>> arguments
>>>> be?
>>> Right now, it's
>>> architecture=x86/address-model=32 architecture=ppc/address-
>>> model=64
>>> In a future version, this will be
>>> architecture=x86 address-model=32 -- architecture=ppc address-
>>> model=64
>>>> I humbly suggest: bjam arch=i386;ppc;x86_64;ppc64
>>> Did you mean to use different separators? ';' used to separate two
>>> different
>>> kinds of things is somewhat confusing.
>>> - Volodya
>>> _______________________________________________
>>> Unsubscribe & other changes:
>> From a user interface perspective, you are separating 2 variables
>> that really go together. The arch and the addressing model need to be
>> together. It is less confusing that way. By having them separate you
>> leave open the possibility of someone listing the archs first then
>> the
>> addressing models second.
> What is "first" and "second" and why the order matters?
>> There is no indication that architecture=x86
>> address-model=32 are actually related to each other when if fact they
>> are very much related.
>> So maybe something like
>> bjam -arch=i386,32 -arch=ppc,64 -arch=sparc,64
>> But those variables really need to be put together.
> I'm afraid I don't understand why the need to be put together. These
> are two variables that can be adjusted independently, and, for native
> compiler cases, a sensible default exists for 32-or-64 option.

I think what Michael is trying to say is that the architecture and the
pointer size are not really independent variables. For instance,
there is no 32-bit version of Intel's Itanium architecture. The
pointer size is part of the definition of an architecture. This is
the point of view that the GCC folks take in their naming of hardware
architectures. In that context, "ppc" is fundamentally 32-bit, and
"ppc64" is 64-bit. Likewise, i386 is 32-bit and x86_64 is 64-bit.
The fact that some chips happen to implement two architectures is not
something that should be built into the nomenclature.

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at