Hi,
Suppose two systems, a Fedora based on gcc 4.1 and a Debian based
on gcc 4.2, both sporting Boost 1.35.0 built with --layout=system,
for simplicity.
Now Joe User writes his app on the Fedora system and links Boost.DateTime
using the familiar -lboost_date_time switch. He builds the app and
tries it on both his Fedora system and the friend's Debian one. What is
going to happen?
BTW, the user is a free software developer and his app is going to be
ported also to other Microsoft, UNIX and popular embedded operating
systems, where Boost has been built mixing --layout=system and
--layout=versioned. Now he faces the problem of linking to the Boost
library of interest. How he is supposed to solve the problem?
This is a new summary of the binary and source portability problems
that current build system is inflicting on the Boost libraries.
My proposal is:
1) dump the --layout= thing, versioned/decorated sonames are always used
2) provide symlinks like the following, when appropriate:
/usr/lib/libboost_date_time-gcc42-1_34_1.so ->
libboost_date_time-gcc42-1_34_1.so.1.34.1
/usr/lib/libboost_date_time-gcc42-d-1_34_1.so ->
libboost_date_time-gcc42-d-1_34_1.so.1.34.1
/usr/lib/libboost_date_time-gcc42-mt-1_34_1.so ->
libboost_date_time-gcc42-mt-1_34_1.so.1.34.1
/usr/lib/libboost_date_time-gcc42-mt-d-1_34_1.so ->
libboost_date_time-gcc42-mt-d-1_34_1.so.1.34.1
3) provide also these symlinks, if desired:
/usr/lib/libboost_date_time.so -> libboost_date_time-gcc42-1_34_1.so
/usr/lib/libboost_date_time-d.so -> libboost_date_time-gcc42-d-1_34_1.so
/usr/lib/libboost_date_time-mt.so -> libboost_date_time-gcc42-mt-1_34_1.so
/usr/lib/libboost_date_time-mt-d.so ->
libboost_date_time-gcc42-mt-d-1_34_1.so
4) add more decorations as required. e.g. Python version to Boost.Python
library name. This way multiple Boost.Python libraries, every built
with a different Python version, could coexist on the same system.
5) provide a program, say boost-config, that may be invoked to find the
right build parameters for a given library, toolset and variant(s).
some examples (suppose default compiler is gcc 4.0, the one used to build
Boost):
$ boost-config --name=DateTime --ldflags
-lboost_date_time-gcc40-1_34_1
$ boost-config --name=DateTime --toolset=gcc-4.1 --variant=mt,d --ldflags
-lboost_date_time-gcc41-mt-d-1_34_1
$ boost-config --name=Threads --toolset=gcc-4.2 --ldflags
-lboost_threads-gcc42-mt-1_34_1
$ boost-config --name=DateTime --toolset=gcc-4.2 --variant=python-2.5
--ldflags
Error: unknown variant python-2.5 for the given library
$ boost-config --name=Python --variant=python-2.4 --ldflags
-lboost_python-gcc40-python24-1_34_1
$ boost-config --name=Python --toolset=gcc-4.2 --variant=python --cxxflags
-I/usr/include/python
if toolset is omitted, the default system compiler is used, if any
(e.g. cc/c++ under linux), otherwise an error is reported.
Point 1) is really optional. In case --layout is kept, the subsequent
points would be related only to --layout=versioned and --layout=system
should be documented as source of any sort of portability issues.
Point 2) is required only on UNIX systems where GNU ld is used, it
might have not sense with other linkers. Every linker has its own story.
Point 3) is applicable only where 2) is and would be handy only when
source portability is not an issue, to the user discretion. Big warning
about source portability should be placed nearby its documentation.
Point 4) would allow packaging Boost.Python on distributions in which
multiple versions of Python may be available.
Point 5) is the way to the complete source portability, at least across
sane systems (read, probably not Windows/MSVC). Note that if Boost is
built using a compiler different from the one asked to boost-config,
the linker will complain about the inexistent library. It would be
easy to make boost-config extract allowed parameter combinations from
an XML file built by Boost.Build at build time.
That's all, good night.
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
