Re: [Boost-build] platform specific object file

From: Jim Gallagher (jim_at_[hidden])
Date: 2008-08-25 15:34:05

Jurko,

Thanks for your help. Using the '..//' syntax makes sense now.

I got things working well on windows, so this morning I worked
on HP-UX for a while. I ran into more problems. :-(

My Jamroot looked like this:

====================================================
# Get VEND_ROOT from the environment
import os ;
VEND_ROOT = [ os.environ VEND_ROOT ] ;

# The only difference between our release and debug
# builds is the NDEBUG macro, which turns off assertions.
# We include debugging info in the release build.
variant MyDebug :
                <threading>multi
                <exception-handling>on
        <asynch-exceptions>off
        <extern-c-nothrow>on
                <warnings>on
                <debug-symbols>on
                <debug-store>object
                <optimization>off
                <runtime-debugging>off
                <runtime-link>shared
;

variant MyReleae :
                MyDebug :
                <define>NDEBUG
;

VendorLibs =
                abc
                def
                xcz
;

# The xerces lib does not follow the same naming convention
# as the other libs, so it appears explicitly below.
VendorWinLibs = lib$(VendorLibs).lib xerces260.lib ;

VendorUnixLibs = -l$(VendorLibs) -lxerces260 ;

project
        : requirements
                <toolset>msvc:<define>WIN32
                <toolset>msvc:<define>_CRT_SECURE_NO_WARNINGS
                <include>BA3Common
                <toolset>msvc:<include>"C:/Program Files/Microsoft Platform SDK/Include"
                <include>$(VEND_ROOT)/include
                <toolset>acc:<linkflags>"-L $(VEND_ROOT)/lib"
                <toolset>acc:<linkflags>$(VendorUnixLibs)
                <toolset>msvc:<linkflags>-libpath:$(VEND_ROOT)/lib
                <toolset>msvc:<linkflags>$(VendorWinLibs)
                <toolset>msvc:<linkflags>"-libpath:\"c:/program files/Microsoft
Platform SDK/lib\""
    ;

alias vendor_main : $(VEND_ROOT)/lib/vend_main.obj :
         <target-os>windows ;

alias vendor_main : $(VEND_ROOT)/lib/vend_main.o :
         <target-os>unix ;

====================================================

On HP-UX, I'm using the aCC compiler. I hope to use the same
filesystem to build both on windows and hp-ux.

The first issue was that user-config.jam was configured for msvc.
Is there a way to make toolset choice automatic based on current OS?

The second issue was that the debug-store feature caused an error
when running bjam on hp-ux. Maybe I need to use
<toolset>msvc:<cflags>/Z7 in the project requirements section?

The third thing I ran into was that on HP-UX, objects that will
go into a shared library must be built with +z (or +Z). I tried
to add a feature to the acc.jam file, like so:

flags acc CFLAGS <pic>on : +z ;
flags acc CFLAGS <pic>off : ;

But that did not work, so I reverted to
<toolset>acc:<cflags>+Z in the project requirements section.

The issues above are relatively minor, but this last one is
pretty important. HP has used PA-RISC CPUs for many years, but is
no longer making PA-RISC systems. All new systems use Itanium
CPUs. The reason this is important is that HP-UX on PA-RISC
uses the non-standard .sl extension for shared libraries. Our
project will need to support both PA-RISC and Itanium shared libraries
for a few years, until all of our PA-RISC systems have been
excessed. If I have a shell command that I can test (not sure
what it is yet), how can I have bjam run that command
at build time to determine the appropriate shared lib extension?

I saw some posts related to this in the archives, but the suggested
patch related to PYTHON_EXTENSION, and I didn't think that was
really the same thing.

One of my future tasks is documenting how Boost Build is used
to build our project, and I intend to make suggestions on
the Boost Build docs at that time.

Thank again for your help,

Jim