Re: Darwin BBv2 CVS library suffix bug

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-18 09:30:43

Mat Marcus <mat-lists_at_[hidden]> writes:

> --On Friday, June 17, 2005 6:45 PM +0400 Vladimir Prus
> <ghost_at_[hidden]> wrote:
>
>> 
>> 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". 

I'm pretty sure part of the reason the requirements didn't carry over
is that cxxflags is a free feature. If you try adding,
e.g. <threading>multi (or however it's spelled in v2) I think you will
see that it carries across.

It's similar to what happens when you add a <define> requirement to
your project. You wouldn't want that impinging on your foreign
project dependencies, would you?

> 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. 

Because arch is not a free feature.

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

I hope I explained above.

> 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.

You can make it a conditional requirement... but that's just a
temporary solution while you wait for us to implement the feature in
Boost.Build v2. Then the flags rule will pick up the feature on the
toolsets that support it, and it will be ignored elsewhere. 

I bet you could figure out how to do it pretty quickly by looking at
tools/build/v1/gcc-tools.jam, tools/build/v2/tools/gcc.jam, and
tools/build/v2/tools/builtin.jam, if you feel like submitting a patch.

>>> 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?

Sorry, what's "this" referring to?

If you mean selecting target architectures, seems like features should
work, no?

> 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)?

Ditto.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com