Boost logo

Boost-Build :

Subject: [Boost-build] [python-port] msvc toolset patch
From: Juraj Ivanèiæ (juraj.ivancic_at_[hidden])
Date: 2011-11-18 13:33:27


Hi all

As I have several years experience with both BB and Python, and a very
short fuse when waiting for bjam to start building a project, I recently
started porting msvc toolset to python and I have reached the point
where I would require some small help. The attached patch contains what
I did so far.

The msvc.py implementation corresponds almost 1-1 to the msvc.jam. IOW I
tried to do it carefully and correctly, without using any fancy Python
features. Currently it is lacking midl/mc support as this requires
porting appropriate jamfiles. I plan on doing this soon.

The first problem I ran into was this:

rule compile.c.pch ( targets + : sources * : properties * )
{
     C++FLAGS on $(targets[1]) = ;
     get-rspline $(targets[1]) : -TC ;
     get-rspline $(targets[2]) : -TC ;
     local pch-source = [ on $(<) return $(PCH_SOURCE) ] ;
     if $(pch-source)
     {
         DEPENDS $(<) : $(pch-source) ;
         compile-c-c++-pch-s $(targets) : $(sources) $(pch-source) ;
     }
     else
     {
         compile-c-c++-pch $(targets) : $(sources) ;
     }
}

This rule is a bit problematic because it decides the action which is to
be taken depending on some of the properties. This is problematic
because, AFAICU, python port uses opposite logic. Generators are given
an action identifier. Only once the action is decided can the rule (or
in this case function) be invoked. Is this correct or did I miss
something? I was unsure how to tackle this problem, so I decided to
leave it until consulting with someone more knowledgeable.

But this was nothing. Who would except that PCH work on the first
attempt, right? But then came another issue is the one which was quite
painful. Even after porting the entire msvc module, I believe correctly,
to Python it still failed to compile a trivial project correctly:

exe test : test.cpp ;

What happens is that BB decides it needs to build test.dll in addition
to test.exe. Not exactly sure why. I did notice that when I change
msvc.link generator so that it no longer accepts IMPORT_LIB as input,
then the DLL is not built, as expected. This led me to the conclusion
that the problem is outside the scope of msvc module, and that there is
some bug in constructing dependency tree. Thoughts?

That about sums it up. Comments and patch reviews are very welcome.

Best regards,
        Juraj Ivanèiæ




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