Re: [Boost-build] Building library with flex/bison inputs with dependencies

Subject: Re: [Boost-build] Building library with flex/bison inputs with dependencies
From: Jim Hague (jim.hague_at_[hidden])
Date: 2015-12-02 11:21:13

On Tuesday 01 Dec 2015 12:13:44 Steven Watanabe wrote:
> > But it looks like the CPP file output by flex is not scanned for include
> > dependencies before compiling; so on random -j builds, GCC will be
> > launched
> > long before Bison is run on e2kmapyacc.yy, with unhappy results.
> 
>   This is supposed to work automatically.
> If it doesn't it's probably a bug.  I
> reworked parts of the header scanning
> algorithm significantly in 2012-2013,
> so your problem may have been fixed.

Thanks!

>   Of particular interest are:
> https://github.com/boostorg/build/commit/64add142e14d5fdfccb7361fed2ea37fb2f
> d2f5b (The end of a long series of patches,
> to fix handling of cyclic INCLUDES,
> which was seriously broken before.)

When I checked, I discovered that the bjam we're using was in fact SVN 83821, 
so includes this change already.

> https://github.com/boostorg/build/commit/c1395b49614ed5c4b0958355ffaa0f794fb
> 760a2 (Handles actions, such as bison, which
> generate multiple targets in a cleaner
> way.  The original code relied on
> marking the outputs as INCLUDing
> each other.  Processing of cyclic
> INCLUDES used to be broken.  See above.)

I'm checking dependencies by running '-d +12' and examining the output. I see 
a dependency for the .o on what I assume is the c-scanner output:

->   2 Name: <pbin/gcc-4.4/debug/link-static/threading-multi>e2kmaplex.o
        Loc: bin/gcc-4.4/debug/link-static/threading-multi/e2kmaplex.o
           : Updating it
           : Depends on bin/gcc-4.4/debug/link-static/threading-multi (stable)
           : Depends on <pbin/gcc-4.4/debug/link-static/threading-multi-
object(c-scanner)@5027>e2kmaplex.cpp (update) (max time)

But c-scanner/e2kmaplex.cpp is given as depending only e2kmaplex.cpp and 
e2kmaplex.ll. I never see a dependency in the logs on the .hpp. Likewise when 
I update the entire Boost.Build tree used to current git head. Should I expect 
to see the header dependency in the logs?

Thanks.
-- 
Jim Hague - jim.hague_at_[hidden]          Never trust a computer you can't lift.