Re: [Boost-build] Bundles (plugins) and rpath install

Subject: Re: [Boost-build] Bundles (plugins) and rpath install
From: J. van der Wulp (jwulp_at_[hidden])
Date: 2008-10-22 05:15:29

Rene Rivera wrote:
> J. van der Wulp wrote:
>> I have compiled a small patch (against trunk) for darwin.jam to allow:
>>  - building of bundles (uses -bundle option instead of -dynamiclib)
>>  - rpath installation
>>
>> The bundle part introduces a feature bundle that is used to choose
>> between the -bundle and -dynamiclib options. The bundle feature may not
>> be the most optimal way of doing this.
> 
> Depends on your definition of optimal ;-) The ideal, from BBv2's point
> of view, is to have a different type of shared target for a bundle. With
> a different type other options can be adjusted without impacting the
> regular shared lib building. And if I remember correctly, just using
> -bundle isn't enough to build bundles.

Currently we use `-bundle -undefined dynamic_lookup' nothing special,
other than that. I must admit that since this is already working for us
I did not look further into bundles/plugins.

I have also created a Boost Build v2 extension for building application
bundles. A couple of years ago this did not seem to exist, has this
changed? My extension is pretty ad hoc but if there is interest I would
like to make improvements so that other people may use it as well in
their own projects. I would be needing some advice though.

> 
>> The install name of a library (-install_name linker option) is the only
>> way I could find to embed the full path into the library. The patch adds
>> prepends $(RPATH[1])/ to the argument of -install_name (used to be just
>> $(<:B)$(<:S)).
> 
> This would be the wrong way to go about doing this. We intentionally put
> the short name so as to allow easier standalone deployment of libs as
> it's what people using Unix are familiar with. Usually it's up to the
> installer, whether it's the user or an install script, to run the
> library renaming program to re-tag the library with the installed path.
> I don't remember the name of the Xcode tool for doing this at the moment
> though.

I agree that would be the better way of doing things. I did not know
such a tool existed. I'll look into it. How hard would it be to
integrate the use of such a  tool with Boost Build installation?

Thanks,

Jeroen