Boost logo

Boost :

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
to "*.so*"?

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

-Steve


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk