>----- Original Message -----
>From: "Bohdan" <[EMAIL PROTECTED]>
>> Honestly ... i'd like to see such build system in all boost
>> non-template libs :) IMHO, it is very convenient.
>>
>> regards,
>> bohdan
>
>The Boost.Build folks are working on a solution for this. I don't know
>quite when it will happen, but a future Boost release will fix all of these
>compile/link option problems with a common scheme.
Rene has done a preliminary implemenation. See his message to the jamboost list below. What is needed now is someone to test his solution to see how it works in practice with various boost libraries, platforms, and compilers. Then give him feedback (on the jamboost list).
Once it is ready for primetime, we need some brief docs explaining what Boost developers need to do to enable the solution for their libraries.
--Beman
[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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
