|
Boost-Build : |
Subject: Re: [Boost-build] [python-port] msvc toolset patch
From: Juraj Ivanèiæ (juraj.ivancic_at_[hidden])
Date: 2011-11-20 17:18:29
On 20.11.2011. 10:06, Vladimir Prus wrote:
> The most expedient solution, I think, is to allow associating 'compile.c.pch' with just python
> function. I think something like attached will be sufficient. Note that 'register_action' already
> accepts a 'function' parameter, so we can port the above jam function into python. It would have
> to use Engine.set_update_action with either 'compile-c-c++-pch-s' or 'compile-c-c++-pch' as real
> action name. Note that I haven't though everything through - there might be more issues downstream.
Perfect. I did not test it yet, but it fits nicely :-)
> Oh, this apparently means that we find the following transformation:
>
> test.cpp -> test.obj -> test.lib + test.dll -> test.exe
>
> This is strange. In jam version, the mechanism to prevent this from happening is check for non-empty
> $(name) in builtin.jam:lib-generator.run. The name is the desired final target name, and is only
> set on the top-level of transformation, so the generator for dll/lib part should get empty name
> and refuse to work.
>
> The same check is present in builtin.py -- so maybe something else is broken, and it's given a
> non-empty name. I think it's best to just set breakpoint in LibGenerator.run and see what's 'name',
> and then work from there. I've tried to check, but things won't work for me on Linux due to import
> of _winreg.
>
> For avoidance of doubt, standard:
>
> import pdb
> pdb.set_trace()
>
> works just fine inside Boost.Build code.
It turns out it was my fault after all. I registered msvc.link and
msvc.link.dll as non-composing generators. I guess I wasn't as careful
as I thought. Now that I have basic scenario working I'll do some more
testing tomorrow as time permits. I'm attaching an updated patch in case
someone is willing to give it a spin, but I expect that it will take a
few more iterations to get it to work well.
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