Re: [jamboost] Re: [Wave] vc-8_0 woes

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-27 09:49:29

On Wednesday 25 May 2005 23:29, David Abrahams wrote:
> Hartmut Kaiser <hartmut.kaiser_at_[hidden]> writes:
> > Reece Dunn wrote:
> >> Looking at http://tinyurl.com/8yqrq, it appears that it is
> >> trying to embed the manifest file into the exe as part of the
> >> resource data associated with it, but for some reason is failing.
> >>
> >> Is this a global problem (i.e. are all projects affected) in
> >> which case it is probably a BBv1 issue. I have built projects
> >> with BBv2, so that appears to be fine (using VC8 beta 2 -
> >> 14.00.50215.44).
> >
> > It seems to be a global problem not related to Wave only (as you pointed
> > out: http://tinyurl.com/8yqrq).
> >
> >> In the build directory, is there the correct EXE file
> >> (because the manifest tool is unable to find it)?
> >
> > When the error occurred first a couple of days ago there was additionally
> > the correct output from the test executable in the logs, but it isn't
> > anymore now.
> >
> > But all I can do from here is to guess... I have no direct access to VC8
> > right now so I'm not able to reproduce it here.
>
> Well, I just checked in a fix that turns off the manifest stuff for
> everything other than Python extension modules. The Python stuff
> still seems to work. I don't know what the rules are for when to do
> the manifest stuff, but this sure is getting more complicated.
>
> And it means that the code I put in Boost.Build v2 to handle manifests
> is going to break everything but Boost.Python with the new system,
> because I don't know how to detect that I'm building a Python module
> in v2.
>
> Hmm, when I look at the arguments to msvc.link.dll for my extension
> module, I do see:
>
> link.dll
> 
> <p..\..\..\bin.v2\libs\python\test\polymorphism2.test\msvc-8.0\debug>polymo
>rphism2_ext.so
> <p..\..\..\bin.v2\libs\python\test\polymorphism2.test\msvc-8.0\debug>polymo
>rphism2_ext-vc80-d-1_33.lib
> <p..\..\..\bin.v2\libs\python\test\polymorphism2.test\msvc-8.0\debug>polymo
>rphism2_ext.rsp
>
> 
> <p..\..\..\bin.v2\libs\python\test\polymorphism2.test\msvc-8.0\debug>polymo
>rphism2.obj
> <p..\..\..\bin.v2\libs\python\build\msvc-8.0\debug>boost_python-vc80-d-1_33
>.lib
>
> : <debug-store>object <debug-symbols>on <define>BOOST_ALL_NO_LIB=1
>
> <exception-handling>on <hardcode-dll-paths>true
> <include>../../.. <include>/C:/Python24/include <inlining>off
> <install-dependencies>off <library-path>/C:/Python24/libs
> <link-runtime>shared <link>shared
> <location-prefix>polymorphism2.test <main-target-type>RUN_PYD ...
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Volodya, why is this target being labelled as type RUN_PYD?! In v1,
> that target type is reserved for the result of running a test on a
> Python extension module. And v2 seems to be written with the same
> intention. Python modules should have type PYD, no?

It's "main-target-type". The 'bpl-test' rule is declared as this:

rule bpl-test ( name : sources * : requirements * )
{ 
sources ?= $(name).py $(name).cpp ;
return [ testing.make-test 
run-pyd : $(sources) /boost/python//boost_python
: $(requirements) : $(name) ] ;
}

And 'make-test' indeed defines main target with the 'run-pyd' type. So the
above output is certainly intended. You're probably looking at a way to check
the type of the actual target we're creating. Unfortunately, it's not possible
from the msvc.link rule. 

It's easy to add this information, by hacking action.actualize (line 679 in my 
copy). However, there's one question -- what if an action produces two 
targets? Which type should be add? Those of the first produced target (recall 
that order of the targets is always the same as specified when declaring a 
generator).

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2