Boost Build V1 Problems.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost Build V1 Problems.

Bernhard Glück
Hi !

I apologize if this is the wrong list to post to, but it seems the most
appropriate to me.

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.
  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. 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 ?

* 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..

* 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

Note: I added the vc-8_0-stlport toolset myself like so:

Contents of vc-8_0-stlport-tools.jam in boostdir/tools/build/v1/

extends-toolset msvc ;

flags $(gCURRENT_TOOLSET) STLPORT_LIB_BASE_NAME ;
STLPORT_LIB_BASE_NAME = stlport_vc80 ;

# bring in the STLPort configuration
SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ;
include stlport.jam ;

# singleton variables...
set-as-singleton VC80_ROOT ;


if ! $(MSVCDir)
{
    if $(VS80COMNTOOLS)
    {
        VC80_ROOT ?= $(VS80COMNTOOLS:J=" ")..\\..\\VC ;
    }
    else
    {
        ProgramFiles ?= $(PROGRAMFILES) ;
        VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio
8\\VC" ;
    }
}

if $(VC80_ROOT)
{
    VC_TOOL_PATH = "$(VC80_ROOT)"\\bin\\ ;
    VC_SETUP = "CALL \"$(VC_TOOL_PATH)vcvars32.BAT\" >nul" ;
}

VC_PDB_NAME = vc80 ;
VC_MANIFEST = "mt -manifest " ;
VC_OUTPUTRESOURCE = -outputresource: ;

feature native-wchar_t : on off ;
flags vc-8_0-stlport C++FLAGS : /Zc:forScope ;
flags vc-8_0-stlport C++FLAGS <native-wchar_t>on : /Zc:wchar_t ;

# The following #// line will be used by the regression test table
generation
# program as the column heading for HTML tables. Must not include
version number.
#//<a
href="http://msdn.microsoft.com/vstudio/whidbey/default.aspx">Micro-<br>soft<br>VC++</a>


_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Boost Build V1 Problems.

Rene Rivera
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
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build