From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-03 00:54:51
I've been trying to stay out of this, but at this point I might as well
say what I've been thinking of as the evenutal approach.
There's currently a hidden feature: if you put an ungristed element into
a target's requirements, that names a rule to be invoked on the
requirements list which can modify that list. For an example, see
select-python-includes in python.jam:
rule select-python-includes ( toolset variant : properties * )
if $(toolset) = gcc
local python-root = $(GCC_PYTHON_ROOT) ;
if <define>BOOST_DEBUG_PYTHON in $(properties)
python-root = $(GCC_PYTHON_DEBUG_ROOT) ;
<include>$(PYTHON_ROOT)/PC # in case the user is using a
return $(properties) ;
We can add new free features which determine not only the subvariant
directory but the name of the actual target, and anyone wanting fancy
staging can write a rule with the above signature which adds
<subdirectory>... and <name>... properties.
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
Sent: Sunday, March 03, 2002 12:33 AM
Subject: Re: [jamboost] Staging Problem
> On 2002-03-01 at 05:48 PM, williamkempf_at_[hidden] (bill_kempf)
> >I've e-mailed Rene about my concerns here before, but I've finally
> >gotten around to proving the problem is real and thought it better to
> >post it to the list this time.
> >The issue is that the staging concept, with the ability to rename
> >files, simply doesn't work for DLLs on the Win32 platform. When
> >import libraries are used (and this is the only DLL usage that
> >Boost.Threads can support since actual dynamic linking would result
> >in premature cleanup of thread local data) the import library does
> >the dynamic loading of the DLL based on the name of the DLL at
> >compile time. When you rename the DLL this means that the import
> >library no longer can load the appropriate DLL.
> >Rene suggested using a utility such as IMPLIB to recreate the import
> >library when staging. This might work, but I'm not sure if it's the
> >right solution. I don't know if IMPLIB will work with all C++ DLLs
> >generated by other compilers, nor do I know about the universal
> >presence of this, or a similar utility, for the various compilers.
> >I'd suggest instead allowing <tag>s to be used in the build commands
> >to modify the output name at compile/link time. This may be a more
> >complicated solution to implement in the Jam rules, but it seems to
> >be the more "proper" solution.
> I agree with Bill on this, even though I know IMPLIB will work, it's
> nicest solution. I don't think the changes to get the tags implemented
> elsewhere are much, just very tricky. I've factored out the rename
> was in the "stage" rule to help if we do this.
> -- grafik - Don't Assume Anything
> -- rrivera_at_[hidden] - grafik_at_[hidden]
> -- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]
> ------------------------ Yahoo! Groups
> Tiny Wireless Camera under $80!
> Order Now! FREE VCR Commander!
> Click Here - Only 1 Day Left!
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to
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