Subject: Re: [boost] [build] Boost modular: Build without version number suffixes
From: Steve M. Robbins (steve_at_[hidden])
Date: 2015-01-27 12:29:53
On January 27, 2015 10:34:39 AM Robert Dailey wrote:
> >> I don't believe there is such an option.
I seem to recall that unversioned was to be the only option in the distant
past. But several of us pushed for matching the system norms. :-)
> >> I will be open to a new value
> >> for
> >> --layout option, say 'bare', that suppresses version
> >> number completely. Robert, since you've already identified the code in
> >> question, and it's not particularly specific to Boost.Build,
> >> would you be interested in submitting a pull request?
> I'd be happy to do a pull request for this.
Be sure not to change only the file name, but also suppress the SOVERSION
embedded in the file itself.
> I realize I could edit the copy script to perform symlink creation or
> copy files with the version number at the end. The problem is this
> introduces conditional logic based on platform (which makes this more
> difficult for me) and also it's much easier to look for *.so. There is
> no clear pattern when a version number is at the end, I'd have to use
> a regular expression to support version number changes later.
If you are currently copying "*.so", wouldn't it be quite easy to change that
> Again I understand this is a platform norm but the function of the
> version number at the end IMHO is to resolve conflicts when installed
> through package manager (so that multiple boost versions can live side
> by side). When I have no need for that, I don't see myself as
> "breaking the norms" by using the name without the version. In fact,
> it's perfectly common to see libs with just *.so at the end. Every
> other library I've built does this out of the box except for Boost.
In fact, that's quite rare. If you look at /usr/lib on most linux
distributions (e.g. Debian) you will see the vast majority are versioned, with
an unversioned .so symlink for link-time.
Also note that unless you take precautions (e.g. using rpath), the run time
loader will in fact look first in the system locations such as /usr/lib and
often including /usr/local/lib for the library. If you don't control the
content of /usr, this leaves you open to obscure bugs where you are running
against something other than what you shipped.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk