From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-08-25 17:29:53
> Thanks for your help. Using the '..//' syntax makes sense now.
> I got things working well on windows,
Good to hear! :-)
> so this morning I worked on HP-UX for a while. I ran into more
> problems. :-(
Now that's not so good... :-(
> 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 :
> variant MyReleae :
I'm guessing you meant 'MyRelease' here.
> MyDebug :
> VendorLibs =
> # 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 ;
> : requirements
> <toolset>msvc:<include>"C:/Program Files/Microsoft Platform SDK/Include"
> <toolset>acc:<linkflags>"-L $(VEND_ROOT)/lib"
> <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?
Your user-config.jam is not the one making the choice of which
toolset you will be using. You select that toolset when running the
build using the toolset property. It is only that when you do not
specify the toolset property explicitly that Boost Build uses the one
that has been configured first, which is most often the first one
configured in your user-config.jam file.
On the other hand, you should be able to detect the current OS in
your user-config.jam file if you need to, the same way you can do this
in any other Jamfile, and use that to decide which toolsets and toolset
versions to configure. For example (warning, untested code):
import os ;
local os-name = [ os.name ] ;
case AIX : ECHO AIX OS ;
case CYGWIN : ECHO Windows OS, running a cygwin built bjam. ;
case AIX : ECHO AIX OS ;
case HPUX : ECHO HP-UX OS;
case LINUX : ECHO Linux OS ;
case NT : ECHO Windows OS, running a native Windows bjam. ;
case * : ECHO '$(os-name)' OS ;
There are also some other data access (e.g. platform, version,
shared-library-path-variable, path-separator, executable-path-variable &
executable-suffix) and utility rules (e.g. on-windows & on-unix)
available in the os.jam module that might come in handy.
For a more complete list of supported OS names grep through the jam
sources (I think the src/jam.h file defines them). But in most cases it
is enough to just output the current [ os.name ] value on the OS you are
> 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?
I am not really sure I get what problem you ran into here? That
feature is defined in and used by the msvc toolset exclusively in Boost
Build. Are you using msvc on HP-UX? As I have not done that or known it
to be possible I can not help you exactly. Perhaps if you describe the
exact problem more precisely...
Looking at the msvc.jam toolset sources: CFLAGS are already set to
/Z7 if <debug-symbols>on/<debug-store>object is set or to /Zi in case
<debug-symbols>on/<debug-store>database is set. So in case of your
MyDebug variant the /Z7 should already be set by the msvc toolset.
> 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.
Not sure what +z does, but you should be able to add this support to
the acc.jam module and get is working. I do not know what exactly you
attempted or tested but the following should work:
- declare a new 'pic' feature (whatever that is) with values on &
off, presumably off being the default.
- add the toolset.flags rule calls as you did above.
- when running the build, make sure the <pic>on property is set for
If you do add something to the acc.jam toolset I suggest well
commenting it, consulting some HP-UX expert on the list (Boris Gubenko
pops to mind :-)) and then posting a patch here so everyone can benefit
from it and you do not need to keep reapplying it with each new Boost
> 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),
Ask on the list for this. Again, Boris Gubenko is generally real
helpful when dealing with anything HP-UX related.
> how can I have bjam run that command
> at build time to determine the appropriate shared lib extension?
Well, there is the built-in SHELL rule that can execute an external
command during the Jamfile parsing phase (and that is exactly the timing
you need for this) and collect its results. There should be many
examples throughout the Boost Build source tree to grep for.
Grepping for through Boost Build sources for PA-RISC though pointed
me to the tools/builtin.jam module. There you can find an <architecture>
feature defined and it has a parisc value. It could be that that could
somehow be used, but I do not see any other location setting it at the
moment. Again, some HP-UX expert should be of assistance here.
> 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.
Well, looking at the python.jam sources I see the
'type.set-generated-target-suffix' used for setting the correct
extension to be used for the PYTHON_EXTENSION target. I guess there
should be no problems with using that same rule for setting the desired
extension of any type, e.g. SHARED_LIB. Grepping for that same rule
through all the Boost Build sources should come up with a few modules
using it to set the correct obj, lib, pch or exe targets at least which
you can then use as examples.
> 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.
Hope this helps.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk