Fw: [C++-sig] continuing problems with bpl & jam

[Rene Rivera]

[2002-08-05] David Abrahams wrote:

>Rene, can you comment on this?
>
>Many thanks,
>Dave
>
>-----------------------------------------------------------
>           David Abrahams * Boost Consulting
>dave at boost-consulting.com * http://www.boost-consulting.com
>
>
>----- Original Message -----
>From: "Srivatsan Raghavan" <vraghavan at cnmnetwork.com>
>To: <c++-sig at python.org>
>Sent: Monday, August 05, 2002 4:14 PM
>Subject: [C++-sig] continuing problems with bpl & jam
>
>
>> after taking dave's earlier info and recompiling using the
>> -sBUILD="debug-python" option
>> i again tried linking to boost_python_pydebug.lib
>> but was still getting the runtime error saying that it can't find
>> boost_python.dll (which it shouldnt' since only boost_python_pydebug.dll
>> is in the path) ..
>> for a while i couldnt' figure out what my problems where.. i was *ONLY*
>> linking to the pydebug version
>> eventually i looked at boost_python_pydebug.lib in gvim, and it appears
>> that the stub is pointing to boost_python.dll , why is this?
>> my reasoning was cause of how jam works..
>> it does all the building and linking in different directories and giving
>> all the various versions (debug python, debug and release) the *SAME*
>> name in their individual directories..
>> then doing a copy & rename of the file.. so that the lib's are still
>> pointing their local version of boost_python.dll but in the \bin-stage
>> directory, that would be the release version ..
>> here is a graphical explanation
>>
>> python\build
>>     bin
>>         boost_pythondll
>>             msvc
>>                 debug\runtime-link-dynamic
>>                         boost_python.lib & boost_python.dll
>>
>>                 debug-python\runtime-link-dynamic
>>                     boost_python.lib & boost_python.dll
>>
>>                 release\runtime-link-dynamic
>>                     boost_python.lib & boost_python.dll
>>     bin-stage
>>         boost_python.dll
>>         boost_python_debug.dll
>>         boost_python_pydebug.dll
>>         #all of these files point to boost_python.dll
>>         boost_python.lib
>>         boost_python_debug.lib
>>         boost_python_pydebug.lib
>>
>>
>>
>> is this problem fixable? and how?

It's a known problem, but I've avoided fixing it until Boost.Build V2 is
out. The plan was to account for this situation directly in V2 as opposed to
trying to hack around it in V1.

Fixing it is a bit entertaining and there are two options I know of... the
first involves adding the renaming that the "stage" target does to happen
before things get moved into the stage so that the above would generate:

python\build\bin\boost_python_pydebug.dll\msvc\debug-python\runtime-link-dynamic
    boost_python_pydebug.lib & *.dll

The other option is to regenerate the *.lib files when they are moved to the
stage. This would involve creating a new target type to invoke IMPLIB (I
think that's the vc tool?).

Doing the second is more of a hack but it's something other people (other
than me :-) can do.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org