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

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2005-06-27 13:58:26

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

- --On Monday, June 27, 2005 5:30 PM +0400 Vladimir Prus <ghost_at_[hidden]>
wrote:

> On Friday 24 June 2005 20:26, Mat Marcus wrote:
> 
>> > However, there's yet another question -- the library still includes
>> > version number (between library name and "dylib"). That will require
>> > that you update your XCode projects when Boost version change. Is that
>> > a problem to you?
>> > 
>> > If yes, I can introduce a way to control naming style with a property
>> > (as opposed to command line switch). Just say a word ;-)
>> 
>> This is great, thanks. 
> 
> So, you'd like to have a property that disables encoding of version?

No, sorry I was unclear, foo.1.33.0.dylib seem fine.

>> There are a few more issues that I ought to mention 
>> with respect to libraries on Mac OS X.
>> 
>> It seems that Apple has broken ar(1) with respect in the case of "fat"
>> .o's (those with code for both -arch i386 and -ar ppc). The only way
>> that I know to continue to use static libraries is to use libtool
>> -static instead of ar for the piecemeal archive rule. I changed my
>> darwin.jam to use libtool, and it seems to work, though I'm not sure of
>> all the ramifications:
>> 
>> actions piecemeal archive
>> {
>> # ar -c -r -s $(ARFLAGS) "$(<:T)" "$(>:T)"
>> libtool -static -o "$(<:T)" $(ARFLAGS) "$(>:T)"
>> }
>> 
>> But even this is not exactly what Apple has been recommending. It seems
>> that static libs are becoming second class citizens. In particular, if an
>> Xcode project builds against static libraries then "fast linking" and
>> "edit and continue" will not work. They suggested that since .o files
>> now have the ability to be comprised of multiple other .o files, we
>> could use them instead. I'm not sure what sort of rule would accommodate
>> this. An example might help to clarify what I am asking. In the current
>> world I might create a static library foo.a from the a.o, b.o and c.o,
>> produced from a.cpp, b.cpp, and c.cpp respectively. Apple has suggested
>> that we replace the library foo.a with a super-object-file foo.o that
>> "contains" a.o, b.o, and c.o, using ld -r. Can such a strategy even work
>> with bbv2, or might it be a good idea to talk to encourage Apple to
>> improve their static library support?
> 
> It's possible to teach V2 that static libraries have .o extension and
> modify the "archive" action to use "ld -r". Just using 
> "type.set-generated-target-suffix" should work. I don't even think that
> will break anything. I am not very happy about such tricks -- making .o
> files into something strange, and I also expect some troubles because
> earlier versions of darwin tools did not support "ld -r" and now it's
> not only possible by recommended way. Optimally, the same "ar" command
> would silently start to produce new format files. However, I doubt that
> Apple will care much about compatibility for build systems.

I will raise it with them, but my expectations are also low. 

>> P.P.S. The other change that I made to the darwin toolset is:
>> 
>> feature isysroot : : free ;
>> 
>> feature arch : none i386 fat : composite ; # We don't turn on
>> link-incompatible for now;
>> flags darwin.compile OPTIONS <arch>fat : -arch i386 -arch ppc -isysroot
>> /Developer/SDKs/MacOSX10.4u.sdk ;
>> flags darwin.compile OPTIONS <arch>i386 : -arch i386 -isysroot
>> /Developer/SDKs/MacOSX10.4u.sdk ;
>> 
>> Is this the right way to go? 
> 
> I think this is fine. But why do you need "composite"?

I see now that I don't. I cut and pasted something from the user manual
without full understanding.

> Also, am I right that you pass the same -isysroot in both cases? Then,
> why it's needed? 

The presence of -arch i386 requires -isysroot
/Developer/SDKs/MacOSX10.4u.sdk . If -arch i386 is absent, there are
several other choices possible for SDK, including the default choice. In
some ways the value of isysroot seems like a "free" feature. But since it
is required in the presence of -arch i386 I'm not really sure what the
natural way to handle it is in bbv2. 

I have a related question. Let's say I go ahead and define <arch> as a
feature. Let's say that in my project's top level JF I have a project
requirement of <arch>fat . Let's also say that my project depends on
boost_filesystem. To get boost_filesystem to build as <arch>fat it seems I
need to say something like 

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

But then my JF will break for platforms for which <arch>fat is not defined.
Do I have to do something ugly like the following?

switch [ os.name ] 
{
case MACOSX :
{
alias boost_filesystem	: /boost/filesystem/<arch>fat ;
}
case * :
{
alias boost_filesystem	: /boost/filesystem ;
}
}

The above solution seems rather coarse. ALso, I have other situations where
an alias should not be built for a given toolset, but I don't know how to
arrange matters in the Jamfile.

>> I will also (locally) add support for the 
>> MACOSX_DEPLOYMENT_TARGET variable following your suggestion from another
>> email.
> 
> Great. Please feel free to ask any questions as you move along.

Thanks again for your help,
Mat

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

iQA/AwUBQsBMVBIZBaoznf65EQK3TwCg9PN+saq4TZNlAsIkSyvRTe64rBAAoKAI
2mw+152d2unUfOMprI1vztTk
=8hU0
-----END PGP SIGNATURE-----