Re: [Boost-build] Boost Build V1 Problems.

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-01-27 11:50:15

Bernhard Glück wrote:
> I apologize if this is the wrong list to post to, but it seems the most 
> appropriate to me.

It's the correct list.

> I am currently setting up a quite large C++ software project, which is 
> being built on multiple platforms ( Win32,Win64,Linux, MacOs ). We have 
> selected Boost::Build v1 as our build system ( wanting to migrate to V2 
> lateron when it is deemed fit for production use by its team )
> 
> Now after working around with it for a few days i have several questions 
> left:
> 
> * Inclusion of libraries
> 
>    For normal external dependencies i add a libpath to my target and 
> state the library name using the <lib> tag.
>    I assume this is the correct way to do so.

"<lib>" is for internal dependencies. That is dependencies that can be 
built directly instead of already being built. You should not need to 
add any libpath for this just to include the 
"<lib>path/to/subproject/libname".

>   However we have boost itself as a dependency of our project. We built 
> boost using its install target so we have
>    a directory include and lib in our dependencies folder ( as built by 
> the install target ). We choose this so we can version the precompiled 
> boost libraries easily.
>   
>   How do i link to those libraries ? THe above way just does not seem to 
> work correctly.

In the requirements of the target, use either:

        <library-path>/some/path
        <find-library>name

Or:

        <library-file>/some/path/libname.lib

With preference for the first one, especially for dynamic libraries.

> And how can i select the correct library based on the 
> current compilation target ? I mean for external ones i use 
> <vc-8_0><*><lib>xxxx etc... but do i have to do it the same way for the 
> boost libraries ? I thought there was some automatic selection of 
> libraries going on ?

For Boost libraries there's auto-linking iff the compiler supports it 
<http://www.boost.org/more/getting_started.html#auto-link> Otherwise, 
and to have portable Jamfiles, you can use the same 
"<vc-8_0><*><library-path>..." selection.

> * Inclusion of platform specific source code.
> 
>    We have several tempalte targets in our build system e.g PgeModule ( 
> which is a library with some special settings) Now i want to add some 
> source code files to a PgeModule derived target based on the platform i 
> am building for and NOT the specific compiler. Can this be achieved ?
> 
>   I thought maybe having a feature <win32> or something like that would 
> help ? But how would i implement it in
> Boost::build ?
> What i basically want is something like this:
> 
>   lib PgeKernel :
>     <win32>WindowWin32.cpp
>     <linux>WindowLinux.cpp
> 
> etc..
> right now i do it baed on the compiler, which seems awfully wordy since 
> i have to repeat the same inclusion for each compiler that potentially 
> targets that platform, and in the case of GCC i am totally stumped ( 
> since it can be used on practially any platform..

Well there's only one target type that supports selection of sources 
based on features, "stage", so you can't have your ideal with BBv1. What 
I do in my projects is for example:

lib libraries
        :
                <template>t-thot-base
                $(LIBSSRC)/base/Blockade.cpp
                $(LIBSSRC)/base/Cache.cpp
                $(LIBSSRC)/base/Thread.cpp
                $(LIBSSRC)/base/ThreadManager.cpp
                $(LIBSSRC)/io/DirectoryWatcher.cpp
                $(LIBSSRC)/io/File.cpp
                $(LIBSSRC)/io/FileSystem.cpp
                $(LIBSSRC)/io/IFF.cpp
                $(LIBSSRC)/io/Reader.cpp
                $(LIBSSRC)/io/MemoryIOStream.cpp
                [ if-platform unix :
                        $(LIBSSRC)/base/Assert-GLIBC.cpp
                        $(LIBSSRC)/base/Process-Unix.cpp
                        $(LIBSSRC)/base/SystemInfo-Unix.cpp
                        $(LIBSSRC)/io/DirectoryWatcher-Linux.cpp
                        $(LIBSSRC)/io/File-STD.cpp
                        $(LIBSSRC)/io/FileSystem-Unix.cpp
                        $(LIBSSRC)/io/Log-POSIX.cpp ]
                [ if-platform win32 :
                        $(LIBSSRC)/base/Assert-Win32.cpp
                        $(LIBSSRC)/base/Process-Win32.cpp
                        $(LIBSSRC)/base/SystemInfo-Win32.cpp
                        $(LIBSSRC)/io/DirectoryWatcher-Win32.cpp
                        $(LIBSSRC)/io/File-Win32.cpp
                        $(LIBSSRC)/io/FileSystem-Win32.cpp
                        $(LIBSSRC)/io/Log-Win32.cpp ]
        :
                [ if-platform win32 : <find-library>mpr ]
        :
                <suppress>true
        ;

The "if-platform" checks the "$(OS)" global variable to match against 
what is passed in:

# Conditional evaluation based on platform tags.
#
rule if-platform ( tags * : values * : else-values * )
{
        local plat = unix ;
        if $(NT) { plat = nt win32 ; }
        if $(MAC) { plat = mac ; }
        if $(OS2) { plat = os2 ; }
        if $(UNIX) { plat = unix ; }
        if $(VMS) { plat = vms ; }
        
        if $(tags:L) in $(OS:L) $(OSPLAT:L) $(plat)
        {
                return $(values) ;
        }
        else
        {
                return $(else-values) ;
        }
}

There's a BBv1 existing pair of rules, "cond" and "unless", you can also 
use if you don't want to write your own as I did. For example:

        [ cond $(NT) : some_win32_file.cpp ]
        [ unless $(NT) : some_posix_file.cpp ]

And so on.

> * STLPORT building of Boost itself.
> 
>    We are using VC8.0 as our default compiler on Windows. However due to 
> the recent STL bug in its shipping Dinkumware STL ( Memory leaks in 
> iostreams ) we decided to go for STLPort on all platforms.
> 
>  However the following build command line:
> 
> bjam "-sTOOLS=vc-8_0-stlport" "-sBUILD=<runtime-link>dynamic 
> <threading>multi <stlport-iostream>on
> <stlport-version>5.0" "-sSTLPORT_PATH=d:\sdk" install
> 
> does not seem to work correctly, e.g the libraries built don't contain 
> reference to STLPort libs and are also not postfixed with the correct 
> stlport postfixes as described in the Docs..
> Note : The d:\sdk path contains a path STLPORT-5.0 containing a prebuilt 
> version of STLPORT 5.1 for VC8

I can't remember if the "-sSTLPORT_PATH=..." logic is working 
correctly... Perhaps you should use the more direct 
"-sSTLPORT_5.0_PATH=d:\sdk\STLPORT-5.0"?

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org