Re: [jamboost] re: Darwin BBv2 CVS library suffix bug

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2005-06-17 12:04:15

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[sorry if this is a duplicate--the first attempt didn't seem to come
through]

- --On Friday, June 17, 2005 6:45 PM +0400 Vladimir Prus
<ghost_at_[hidden]> wrote:

> On Thursday 16 June 2005 21:59, Mat Marcus wrote:

[snip]

>> > Probably, we should be adding the suffix only when building Boost
>> > itself for install (that is via "bjam stage" or "bjam install" in
>> > Boost root), and not in any other case?
>> 
>> This sounds promising. 
> 
> I'll try to implement this on Monday, then.

Great, thanks.

> 
>> Life for OSX boost users may also be 
>> complicated by the new "Universal" binary format. That is,
>> developers will need to produce applications that will run on both
>> Intel and PPC macs. So a boost install could involve building and
>> installing both Intel and PowerPC versions of the libraries. 
> 
> Hmm.. does passing "cxxflags="-arch i386 -arch ppc" work at the
> moment?

Yes, this works, although it raises another question for me. In our
current build directory organization, boost is a sub-project. The
fact that boost has its own "top-level" complicates cxxflags usage to
some extent. For example, let's say that my whole project tree is
rooted in the directory root/ with boost in root/boost. In my top
level Jamfile.v2, located in root/ I tried adding the following
requirement:

project adobe 
: requirements
<cxxflags>"-arch i386 -arch ppc" ;
# etc

This worked as expected for all of my own sub-projects, but not for
boost, which is currently built as:

alias boost_filesystem : /boost/filesystem ;
#etc

I assume this failure was because it "has its own root". On the other
hand when I added a feature:

import feature : feature ;

feature arch : none fat : composite ;
feature.compose <arch>fat : <cxxflags>"-arch i386 -arch ppc" ;

and then built boost as:

alias boost_filesystem : /boost/filesystem/<arch>fat ;
#etc

the build flags propagate to the boost libs. 

*** Question 1: I would like to understand why one technique works,
but not the other. 

The latter technique has the benefits adding the architecture
dimension to the directory structure, but it will force me to write
conditional code to only set the architecture on os/toolsets that
support it.

>> For shared libraries, I 
>> believe that these can be bundled together in a OSX/darwin-specific
>> entity known as a framework. 
> 
> I still have very vague idea what's framework is... Guess I'll
> print some Apple docs now.

That would be great. This might help:

<http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/index.html>

The Apple docs have changed quite a bit in the last week with Apple's
announcement of their switch to Intel, and their release of the XCode
2.1 cross-development IDE. Most Mac programmers are not yet familiar
with the new build flags. Some useful supplements to the
documentation you might find exist at the links below. Apple's
instructions tend to assume that developers will be using XCode+gcc,
rather than bbv2+gcc, but I've been looking at the XCode build logs
to see the real flags passed to gcc, etc.

<http://devworld.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_intro/chapter_1_section_1.html>
<http://devworld.apple.com/releasenotes/DeveloperTools/GCC40PortingReleaseNotes/index.html#//apple_ref/doc/uid/TP40002069>

These may give you some idea about "universal" artifacts and gcc 4.0
changes. In addition to the various combinations of -arch settings,
there are two other build variables of which I am aware. First, the
toolchain's behavior is affected by the environment variable,
MACOSX_DEPLOYMENT_TARGET, which typically is set somewhere between
10.1 and 10.4 at the moment, and determines the oldest OS version
upon which the targeted artifacts will run. 

*** Question 2
Is there an existing bbv2 paradigm into which we can shoehorn this
notion?

The other variable is which version of the SDK must be used. To
support the Intel architecture one must use a new enough SDK using: 

-syslibroot /Developer/SDKs/MacOSX10.4u.sdk

*** Question 3
What is the best way to support this in my Jamfile.v2's (or in bbv2
itself)?

More (older) docs on MACOSX_DEPLOYMENT_TARGET and -syslibroot :

<http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/Articles/cd_overview.html>

Thanks for your attention,
Mat

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.1 (Build 2185)

iQA/AwUBQrMCkRIZBaoznf65EQIbQgCfWy79fTJRg/B7zLcAVF7iU5KrnQoAoPOH
mnB5amQTaAuE3F0g14SKe0px
=w7D8
-----END PGP SIGNATURE-----