Boost-Build :

Date view	Thread view	Subject view	Author view

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-16 08:59:21

Next message: brock_peabody: "Re: threads + cygwin + Boost.Build V2"
Previous message: Mark Sheppard: "RE: [jamboost] Boost.Jam without Boost?"
Next in thread: Pedro Ferreira: "Re: [jamboost] Improved linking mechanism"
Reply: Pedro Ferreira: "Re: [jamboost] Improved linking mechanism"
Reply: David Abrahams: "Re: Improved linking mechanism"

All,
I attach a proposal for a somewhat refined linking mechanism for V2. The
primary goal is to avoid requiring to use

lib a : a.cpp : <use>b : : <library>b ;

everytime one wants to use a library. It seems it's implementable without much
effort.

I'd appreciate all comments on this document.

TIA,
Volodya

--Boundary-00=_5Qqj/ypDYk8cvzz Content-Type: text/html;
charset="us-ascii";
name="linking.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="linking.html"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=koi8-r">
<TITLE></TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1 (Linux)">
<META NAME="AUTHOR" CONTENT="Vladimir Prus">
<META NAME="CREATED" CONTENT="20031015;15444000">
<META NAME="CHANGEDBY" CONTENT="Vladimir Prus">
<META NAME="CHANGED" CONTENT="20031016;16362400">
<STYLE>

</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1>Improved library linking mechanism</H1>
<H2>Motivation</H2>
When V2 first got the <library> feature, it was a good idea.
Together with usage requirements is allowed to link to a library
without bothering about transitive dependency on other libraries,
which must be linked as well. Unfortunately, the current model has a
couple of drawbacks:
<UL>
<LI>it requires more typing than necessary
<LI>it does not allow to directly link one library to another
one, for shared linking, and yet doing something sensible for static
linking.
</UL>
This document discusses what can be improved and proposes a
solution which can be implemented with little effort.
<H2>Overview</H2>
Assume executable “m” uses library “a”,
and that library uses another library, “b”. Naturally,
the code of “b” should be somehow available when “m”
is run. There are two different ways how we can achieve this:
<UL>
<LI>Direct linking means that “a” library contains
reference to library “b”. On common toolsets, it's only
possible is “a” is a shared library. In this case, “b”
will be automatically found at runtime. The problem with this
solution is that it will just break for static build.
<LI>Bubble-up linking meands that “a” does not
contain a reference to “b”. However, when the library is
build, Boost.Build is told about dependency on “b”, and
“b” will be automatically linked to “m”. The
problem with this solution, as described in docs, is that it's
pretty verbose. For our example, the declaration of “a”
might look like:
</UL>
lib a : a.cpp : <use>b : :
<library>b ;
The duplication of “b” is
not nice.

 

<H2>Proposal</H2>
It was proposed by Ali, IIRC, that putting library in sources of
other library does the right thing: use direct linking if the library
is build as shared, and use bubble-up if library is linked as static.
Later, Christopher Currie noted that for static linking, libraries in
sources of other libraries are passed through by the current code,
which opens an easy path for implementation.
Accordingly, it's proposed that dependency from one library to
another can be expressed in two ways:
<UL>
<LI>Automatic: “lib a : a.cpp b ;”. When building
with <link>shared, direct linking is used. Otherwise, “b”
is returned together with targets created for “a” and
this will be effectively the same as bubble-up linking.
<LI>Bubble-up: “lib a : a.cpp : <use>b : : <library>b
;”. For both static and shared linking, “b” is not
linked it but is returned as usage-requirement.
</UL>
Let's consider interactions between two libraries “a”
and “b”, where “a” depends on “b”
and “b” might depend on other libraries. Each cell of the
following table documents what target are created when building “b”
and how they are handled.
<TABLE WIDTH=100% BORDER=1 BORDERCOLOR="#000000" CELLPADDING=4 CELLSPACING=3>
<COL WIDTH=64*>
<COL WIDTH=64*>
<COL WIDTH=64*>
<COL WIDTH=64*>
<THEAD>
<TR VALIGN=TOP>
<TH WIDTH=25%>
 

</TH>
<TH WIDTH=25%>
B: automatic/static
</TH>
<TH WIDTH=25%>
B: automatic/shared
</TH>
<TH WIDTH=25%>
B: bubble up
</TH>
</TR>
</THEAD>
<TBODY>
<TR VALIGN=TOP>
<TH WIDTH=25%>
B creates:
</TH>
<TD WIDTH=25%>
“b” target and target for “b”
dependendies.
</TD>
<TD WIDTH=25%>
 A single target for “b”
</TD>
<TD WIDTH=25%>
A single target for “b” and <library> usage
requirements
</TD>
</TR>
<TR VALIGN=TOP>
<TH WIDTH=25%>
A: automatic/static
</TH>
<TD WIDTH=25%>
Targets are returned together with the target for “a”
</TD>
<TD WIDTH=25%>
Target is returned together with the target for “a”
</TD>
<TD WIDTH=25%>
Target for “b” and targets in usage requirements
are returned.
</TD>
</TR>
<TR VALIGN=TOP>
<TH WIDTH=25%>
A: automatic/shared
</TH>
<TD WIDTH=25%>
All targets are directly linked
</TD>
<TD WIDTH=25%>
The target is directly linked.
</TD>
<TD WIDTH=25%>
The targets are directly linked.
</TD>
</TR>
<TR VALIGN=TOP>
<TH WIDTH=25%>
A: bubble up
</TH>
<TD WIDTH=25%>
Targets are returned in usage requirements.
</TD>
<TD WIDTH=25%>
Targets are returned in usage requirements.
</TD>
<TD WIDTH=25%>
Targets are returned in usage requirements.
</TD>
</TR>
</TBODY>
</TABLE>
 

To implement the above scheme we need two mechanism. One which
cause “b” target to be returned without processing when A
is linked statically, and the second to achieve the same processing
for <library> properties returned as usage requirements by “b”.
The first mechanism is already in
place. If generator for static library sees another library as
source, that library is bypassed. The second mechanism requires that
<library> properties are treated as sources when building
library target. This can be archieved by tweaking the “construct”
method of the “lib-target-class” class.
 

<H2>Implementation</H2>
The presented proposal requires two changes to the existing code:
<UL>
<LI>The “construct” method of the “lib-target-class”
should find all <library> properties an add it to the list of
sources. After that, it can call inherited “construct”
<LI>For “searched” libraries, current code contains a
special code. It look at all the <library> properties, finds
which refer to searched libraries and adds special
<find-shared-library> and <find-static-library>
features, which are converted by toolset into -l switches to the
linker. When <library> is converted into source, this logic
should be adjusted and moved to the “generated-targets”
method of the “linking-generator” class.
</UL>
<HR>
Last modified: <SDFIELD TYPE=DOCINFO SUBTYPE=CHANGE FORMAT=DATE SDNUM="1049;1033;MMM D, YYYY">Oct 16, 2003</SDFIELD>
</BODY>
</HTML> --Boundary-00=_5Qqj/ypDYk8cvzz--

Next message: brock_peabody: "Re: threads + cygwin + Boost.Build V2"
Previous message: Mark Sheppard: "RE: [jamboost] Boost.Jam without Boost?"
Next in thread: Pedro Ferreira: "Re: [jamboost] Improved linking mechanism"
Reply: Pedro Ferreira: "Re: [jamboost] Improved linking mechanism"
Reply: David Abrahams: "Re: Improved linking mechanism"

Date view	Thread view	Subject view	Author view

Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk