Re: [jamboost] Re: Standardization of build

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-07-20 17:30:02

[2003-07-16] Rene Rivera wrote:

>The way to handle the maintainance aspect is to standardize what the naming
>behaviour is for libraries and dlls and codify that into either the stage
>rule, or preferably another rule which better describes the intent.

OK I've done some of the work on this. I did some additions and
modifications to the default build, what you get when running bjam at the
boost_root. The changes are...

In boost_root/Jamfile:

Has two default stage targets. One for the built libraries, and another
for the include directory. The targets build to what one would consider
"install" locations. Specifically C:\Boost, or /usr/local.

The libraries are installed to a subdirectory according to the platform.
For example /usr/local/lib/x86-linux on Linux systems. This supports
multi-system nature of installs. The libraries are tagged with a build
specific tag with the addition of the "common-stage-tag" rule (see below).

The includes are searched in the boost/.. tree and copied to a version
specific subdirectory. Example, C:\Boost\include\boost-131\boost.

Added some command options to control install locations, and a --help
option. They are in the style of configure options. Do a "bjam --help" to
see docs for those.

In boost_root/tools/build/boost-base.jam:

Added various options to stage rule to handle the above functionality:
<architecture-subdirs>, adds a single level subdir to the stage that
encode the architecture and OS of the build.
<tree-subdir>TREE-ROOT, attempts to mirror the given rooted tree. Any
source files that have the root will be created within the subdir(s) where
the source is, but within the stage dir.
<locate>DIR, roots the stage at the given dir instead of placing it at
the project location (or ALL_LOCATE_TARGET).

Added the "common-stage-tag" rule, which generates the common tag when
used in the requirements section of a stage. The tag generated is documented
in the rule, but I'll quote the docs here:

# Common rules for generating a single stage tag based on the
# variant, build properties, and the toolset used to build.
# To use place this rule name in the requirementes section of
# a stage target.
#
# The tag is constructed as such:
#
# [-<toolset-tag>][-<thread-tag>][-<runtime-tag>]
#
# <toolset-tag> maps to an abbreviated name of the toolset
# and when possible and applicable the version of the toolset.
#
# <thread-tag> "mt" when multi-threading is enabled.
#
# <runtime-tag> adds these single letter tags:
# "s" when static linking to runtime
# "g" when linking to debug runtime
# "d" when building debug variants
# "p" when building with stlport libraries
#
# The tag added is a <tag><prefix> to allow for additional tags
# in the stage. For example the version tag.
#
rule common-stage-tag ( toolset variant : properties * )

***

The changes to the two files are in the "build_for_distribution" branch.
Only the two files are tagged to the branch so only get the files not the
whole tree.

Questions, comments, whatever?

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq