Re: [Boost-build] platform specific object file

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-08-25 17:29:53

   Hi Jim.

> 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 :
> 		<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 :

   I'm guessing you meant 'MyRelease' here.

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

   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 ] ;
   switch $(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 
interested in.

> 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 
your target.

   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 
Build release.

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

   Cool, thanks!

   Hope this helps.

   Best regards,
     Jurko Gospodnetić