[Boost-build] [python-port] msvc toolset patch

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æ