Dependency scanning details (Was: [BBv2] Patch, review needed - support of Microsoft .idl files for MSVC)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-10-26 02:31:34

On Wednesday 19 October 2005 22:13, Alexey Pakhunov wrote:
> Reece Dunn wrote:
> > [3] This is more a BBv2/bjam issue: when scanning for dependencies, it
> > only scans one level deep, so doesn't pick up things like:
> >
> > mycomobj.cpp
> > #include "stdafx.h"
> >
> > stdafx.h
> > #include "myidl.h"
> >
> > so myidl will be built after mycomobj!
>
> In this case the dependency graph looks like this:
>
> ----
> <p../core-object(c-scanner)@134>mycomobj.cpp
> <p../core>mycomobj.cpp
> <object(c-scanner)@134#..\core>stdafx.h
> <object(c-scanner)@134#..\core>myidl.h
>
> myidl.h
> <p..\core\bin\msvc-8.0\debug>myidl.h
> <p../core-object(midl-scanner)@131>myidl.idl
> <p../core>myidl.idl
> ----
>
> There is no link between mycomobj.cpp and myidl.idl. One of the reasons
> is presence of 'c-scanner' and 'midl-scanner' in grists. Vladimir, do
> you know why we need to put scanner type in the grist?

The idea was that a single source file can be used by several actions, which 
which have different properties, and different scanners. Say, you can compile 
the same source with two different include paths, and clearly scanners should 
be different. That's why the scanner is in grist.

The dependency graph part you show above has nothing wrong BTW. Yes, 

<object(c-scanner)@134#..\core>myidl.h

target includes grist. But when bjam tries to find this target, it should 
notice 

<p..\core\bin\msvc-8.0\debug>myidl.h

and make the necessary connection from the first to the second. Are you sure 
the second file's path is added to include path from mycomobj.cpp?

If thing still don't work, send me a simple testcase, and I'll take a look.

- Volodya

>
> Best regards/Venlig hilsen,
> Alexey Pakhunov.
>
>
>
>
>
> Yahoo! Groups Links
>
>
>

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