|
@@ -105,10 +105,10 @@ whatever get_whatever();
|
|
|
although you probably shouldn't need to: </P>
|
|
although you probably shouldn't need to: </P>
|
|
|
<UL>
|
|
<UL>
|
|
|
<LI>
|
|
<LI>
|
|
|
- If you <EM>don't</EM> use these in the library source files (but do in your
|
|
|
|
|
- library's headers) and the user attempts to compile the library source with a
|
|
|
|
|
- non-default ABI setting, then they will get compiler errors if there are any
|
|
|
|
|
- conflicts.</LI>
|
|
|
|
|
|
|
+ If you <EM>don't</EM>
|
|
|
|
|
+ use these in the library source files (but do in your library's headers) and
|
|
|
|
|
+ the user attempts to compile the library source with a non-default ABI setting,
|
|
|
|
|
+ then they will get compiler errors if there are any conflicts.
|
|
|
<LI>
|
|
<LI>
|
|
|
If you <EM>do </EM>include them in both the library's headers and the library
|
|
If you <EM>do </EM>include them in both the library's headers and the library
|
|
|
source files, then the code should always compile no matter what the compiler
|
|
source files, then the code should always compile no matter what the compiler
|
|
@@ -138,11 +138,11 @@ whatever get_whatever();
|
|
|
as to which is supported by default:</P>
|
|
as to which is supported by default:</P>
|
|
|
<UL>
|
|
<UL>
|
|
|
<LI>
|
|
<LI>
|
|
|
- On Unix platforms it typically makes no difference to the code: the user just
|
|
|
|
|
- selects in their makesfile which library they prefer to link to.</LI>
|
|
|
|
|
|
|
+ On Unix platforms it typically makes no difference to the code: the user just
|
|
|
|
|
+ selects in their makesfile which library they prefer to link to.
|
|
|
<LI>
|
|
<LI>
|
|
|
- On Windows platforms, the code has to be specially annotated to support DLL's,
|
|
|
|
|
- so we need to pick one option as the default and one as an alternative.</LI>
|
|
|
|
|
|
|
+ On Windows platforms, the code has to be specially annotated to support DLL's,
|
|
|
|
|
+ so we need to pick one option as the default and one as an alternative.
|
|
|
<LI>
|
|
<LI>
|
|
|
On Windows platforms, we can inject special code to automatically select which
|
|
On Windows platforms, we can inject special code to automatically select which
|
|
|
library variant to link against: so again we need to decide which is to be the
|
|
library variant to link against: so again we need to decide which is to be the
|
|
@@ -357,122 +357,18 @@ libboost_regex-vc71-sgd-1_31.lib
|
|
|
<H2><A name="build_changes"></A>Changes Affecting the Build System</H2>
|
|
<H2><A name="build_changes"></A>Changes Affecting the Build System</H2>
|
|
|
<H3><a name="build"></a><A name="jamfile"></A>Creating the library Jamfile</H3>
|
|
<H3><a name="build"></a><A name="jamfile"></A>Creating the library Jamfile</H3>
|
|
|
<P>The Jamfile for building library "whatever" typically lives in
|
|
<P>The Jamfile for building library "whatever" typically lives in
|
|
|
- boost-root/libs/whatever/build, start by defining the project root for the
|
|
|
|
|
- Jamfile:</P>
|
|
|
|
|
- <PRE>subproject libs/whatever/build ; </PRE>
|
|
|
|
|
- <P>Then add the static library build target (if supported):</P>
|
|
|
|
|
- <PRE>lib
|
|
|
|
|
- boost_whatever
|
|
|
|
|
- : # list all the sources for this
|
|
|
|
|
- library:
|
|
|
|
|
- ../src/whatever.cpp
|
|
|
|
|
- : # all build requirements go
|
|
|
|
|
- here. # the "common-variant-tag" rule ensures that the library will
|
|
|
|
|
- # be named according to the rules used by the install
|
|
|
|
|
- # and auto-link features:
|
|
|
|
|
- common-variant-tag
|
|
|
|
|
- # set include path for Boost headers:
|
|
|
|
|
- <sysinclude>$(BOOST_ROOT)
|
|
|
|
|
- :
|
|
|
|
|
- # list default build variants here
|
|
|
|
|
- debug release
|
|
|
|
|
- ; </PRE>
|
|
|
|
|
- <P>Then add the dll build target (if supported). In this case the build
|
|
|
|
|
- requirements section get an extra define: so that our sources know to export
|
|
|
|
|
- their own symbols (and import those from any other boost libs on which we may
|
|
|
|
|
- be dependent). We also restict shared library builds to dynamic-runtime
|
|
|
|
|
- build variants, if we don't do this then dll's linked against static runtimes
|
|
|
|
|
- are unlikely to function correctly (the dll will have a separate runtime from
|
|
|
|
|
- the executable using it, this generally causing problems with new and
|
|
|
|
|
- delete, as well as exception handling runtimes).</P>
|
|
|
|
|
- <PRE>dll
|
|
|
|
|
- boost_whatever
|
|
|
|
|
- : # list all the sources for this
|
|
|
|
|
- library:
|
|
|
|
|
- ../src/whatever.cpp
|
|
|
|
|
- : # all build requirements go
|
|
|
|
|
- here. # the "common-variant-tag" rule ensures that the library will
|
|
|
|
|
- # be named according to the rules used by the install
|
|
|
|
|
- # and auto-link features:
|
|
|
|
|
- common-variant-tag
|
|
|
|
|
- # tell our source that we're building (and maybe using) dll's:
|
|
|
|
|
- <define>BOOST_ALL_DYN_LINK=1
|
|
|
|
|
- # only build this for dynamic runtimes:
|
|
|
|
|
- <runtime-link>dynamic
|
|
|
|
|
- # set include path for Boost headers:
|
|
|
|
|
- <sysinclude>$(BOOST_ROOT)
|
|
|
|
|
- :
|
|
|
|
|
- # list default build variants here
|
|
|
|
|
- debug release
|
|
|
|
|
- ;
|
|
|
|
|
-</PRE>
|
|
|
|
|
- <P>Now add an install target so that Boost.Install can find this library to
|
|
|
|
|
- install:</P>
|
|
|
|
|
- <pre>install whatever lib
|
|
|
|
|
- : <dll>boost_whatever <lib>boost_whatever
|
|
|
|
|
- ;
|
|
|
|
|
-</pre>
|
|
|
|
|
- <P>Finally add a stage target that will copy the built libraries to a common
|
|
|
|
|
- sub-directory (boost-root/stage/lib):</P>
|
|
|
|
|
- <PRE>stage stage/lib : <lib>boost_whatever <dll>boost_whatever
|
|
|
|
|
- :
|
|
|
|
|
- # copy to a path rooted at BOOST_ROOT:
|
|
|
|
|
- <locate>$(BOOST_ROOT)
|
|
|
|
|
- # make sure the names of the libraries are correctly named:
|
|
|
|
|
- common-variant-tag
|
|
|
|
|
- # add this target to the "stage" and "all" psuedo-targets:
|
|
|
|
|
- <target>stage
|
|
|
|
|
- <target>all
|
|
|
|
|
- :
|
|
|
|
|
- debug release
|
|
|
|
|
- ;
|
|
|
|
|
-</PRE>
|
|
|
|
|
|
|
+ boost-root/libs/whatever/build, the only extra step required is to add a
|
|
|
|
|
+ <define> requirement to the library target so that your code knows
|
|
|
|
|
+ whether it's building a dll or static library, a typical Jamfile would like
|
|
|
|
|
+ like this:</P>
|
|
|
|
|
+ <PRE>
|
|
|
|
|
+lib boost_regex : ../src/whatever.cpp :
|
|
|
|
|
+ <link>shared:<define>BOOST_WHATEVER_DYN_LINK=1 ;
|
|
|
|
|
+ </PRE>
|
|
|
<H3><A name="testing"></A>Testing Auto-linking</H3>
|
|
<H3><A name="testing"></A>Testing Auto-linking</H3>
|
|
|
- <P>Testing the auto-link feature reasonable straightforward using
|
|
|
|
|
- the Boost.build system: we need to build the "whatever" library's test
|
|
|
|
|
- files without explicitly specifying the library to link to in the Jamfile, for
|
|
|
|
|
- example:</P>
|
|
|
|
|
- <PRE>subproject libs/whatever/test/auto-link-test ;
|
|
|
|
|
-
|
|
|
|
|
-# bring in the rules for testing
|
|
|
|
|
-import testing ;
|
|
|
|
|
-
|
|
|
|
|
-# start with a static linking version:
|
|
|
|
|
-
|
|
|
|
|
-run
|
|
|
|
|
- # sources
|
|
|
|
|
- ../whatever_test.cpp
|
|
|
|
|
- :
|
|
|
|
|
- : # input files
|
|
|
|
|
- : # requirements
|
|
|
|
|
- <library-path>../../../../stage/lib
|
|
|
|
|
- <define>BOOST_LIB_DIAGNOSTIC=1
|
|
|
|
|
- : # program name
|
|
|
|
|
- whatever_test
|
|
|
|
|
- ;
|
|
|
|
|
-
|
|
|
|
|
- # and then a dll linking version:
|
|
|
|
|
- run
|
|
|
|
|
- # sources
|
|
|
|
|
- ../whatever_test.cpp
|
|
|
|
|
- :
|
|
|
|
|
- : # input files
|
|
|
|
|
- : # requirements
|
|
|
|
|
- <library-path>../../../../stage/lib
|
|
|
|
|
- <define>BOOST_LIB_DIAGNOSTIC=1
|
|
|
|
|
- <define>BOOST_ALL_DYN_LINK=1
|
|
|
|
|
- <runtime-link>dynamic
|
|
|
|
|
- : # program name
|
|
|
|
|
- whatever_test_dll
|
|
|
|
|
- ;
|
|
|
|
|
-
|
|
|
|
|
-</PRE>
|
|
|
|
|
- <P>Please note however that this Jamfile will only build with compilers that do
|
|
|
|
|
- actually support auto-linking, so it should not be added to the regular
|
|
|
|
|
- regression tests. The Jamfile should also be built for all possible build
|
|
|
|
|
- variants, for the Microsoft / Borland compilers that means doing a:</P>
|
|
|
|
|
- <PRE>bjam -sBUILD="release debug <threading>multi/single <runtime-link>static/dynamic" test
|
|
|
|
|
- </PRE>
|
|
|
|
|
|
|
+ <P>Testing the auto-link feature is somewhat convoluted, and requires access
|
|
|
|
|
+ to a compiler that supports the feature: refer to <A href="../libs/config/test/link/test/Jamfile.v2">
|
|
|
|
|
+ libs/config/test/link/test/Jamfile.v2</A> for an example.</P>
|
|
|
<HR>
|
|
<HR>
|
|
|
<p><A name="copyright"></A>Revised
|
|
<p><A name="copyright"></A>Revised
|
|
|
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
|
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
|
@@ -487,4 +383,3 @@ run
|
|
|
attribution then please provide a link to this article.</EM></P>
|
|
attribution then please provide a link to this article.</EM></P>
|
|
|
</body>
|
|
</body>
|
|
|
</html>
|
|
</html>
|
|
|
-
|
|
|