Re: [jamboost] Staging Problem

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) ;
}
properties +=
<include>$(python-root)/include/python$(PYTHON_VERSION) ;
}
else
{
properties +=
<include>$(PYTHON_ROOT)/include
<include>$(PYTHON_ROOT)/PC # in case the user is using a
source installation
<debug-python><define>_DEBUG
;
}
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]>
To: <jamboost_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)
wrote:
>
> >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
not the
> 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
code that
> 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
Sponsor ---------------------~-->
> Tiny Wireless Camera under $80!
> Order Now! FREE VCR Commander!
> Click Here - Only 1 Day Left!
> http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/z3wwlB/TM
> ---------------------------------------------------------------------~
->
>
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>