Re: [Boost-build] generator problems

Subject: Re: [Boost-build] generator problems
From: George Georgiev (george.georgiev.sf_at_[hidden])
Date: 2012-03-22 23:31:09

Hi,

Something that I can not understand is how the scanner will be able to
detect the dependencies if the files are still not generated. I feel
like the right solutions is in scanner.process to be added fake
propagation explaining the expected dependencies. In pseudo code:

    rule process ( target : matches * : binding )
    {
        ...

        local cpp = get cpp target from $(target);
        headers = get h targets from $(matches);
        INCLUDES $(cpp) : $(headers) ;
    }

Unfortunately I am laking a basic knowledge of jam language and every
experiment takes me forever to implement.

Thanks,
George

On Thu, Mar 22, 2012 at 8:07 PM, George Georgiev
<george.georgiev.sf_at_[hidden]> wrote:
> Hi Steven,
>
> Unfortunately this has exactly the same issue like the other:
>
> C:\Users\George\generator\test>b2 link=static lib1
> ...found 42 targets...
> ...updating 20 targets...
> common.mkdir bin\msvc-10.0
> common.mkdir bin\msvc-10.0\debug
> common.mkdir bin\msvc-10.0\debug\link-static
> common.mkdir bin\msvc-10.0\debug\link-static\pch-off
> common.mkdir c:\Users\George\generator\compil\bin
> common.mkdir c:\Users\George\generator\compil\bin\msvc-10.0
> common.mkdir c:\Users\George\generator\compil\bin\msvc-10.0\debug
> common.mkdir c:\Users\George\generator\compil\bin\msvc-10.0\debug\link-static
> common.mkdir c:\Users\George\generator\compil\bin\msvc-10.0\debug\link-static\pch-off
> common.mkdir c:\Users\George\generator\compil\bin\msvc-10.0\debug\link-static\pch-off\threading-multi
> compile-c-c++ c:\Users\George\generator\compil\bin\msvc-10.0\debug\link-static\pch-off\threading-multi\compil.obj
> compil.cpp
> msvc.link c:\Users\George\generator\compil\bin\msvc-10.0\debug\link-static\pch-off\threading-multi\generator.exe
> msvc.manifest c:\Users\George\generator\compil\bin\msvc-10.0\debug\link-static\pch-off\threading-multi\generator.exe
> jamcompil.generate bin\msvc-10.0\debug\link-static\pch-off\lib1-1.cpp
> compile-c-c++ bin\msvc-10.0\debug\link-static\pch-off\lib1-1.obj
> lib1-1.cpp
> c:\users\george\generator\test\bin\msvc-10.0\debug\link-static\pch-off\lib1-1.h(2)
> : fatal error C1083: Cannot open include file: 'lib1-2.h': No such
> file or directory
>
>    call "C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\vcvarsall.bat" x86 >nul
> cl /Zm800 -nologo @"bin\msvc-10.0\debug\link-static\pch-off\lib1-1.obj.rsp"
>
> ...failed compile-c-c++ bin\msvc-10.0\debug\link-static\pch-off\lib1-1.obj...
> jamcompil.generate bin\msvc-10.0\debug\link-static\pch-off\lib1-2.cpp
> compile-c-c++ bin\msvc-10.0\debug\link-static\pch-off\lib1-2.obj
> lib1-2.cpp
> c:\users\george\generator\test\bin\msvc-10.0\debug\link-static\pch-off\lib1-1.h(3)
> : fatal error C1083: Cannot open include file: 'lib2-2.h': No such
> file or directory
>
>    call "C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\vcvarsall.bat" x86 >nul
> cl /Zm800 -nologo @"bin\msvc-10.0\debug\link-static\pch-off\lib1-2.obj.rsp"
>
> ...failed compile-c-c++ bin\msvc-10.0\debug\link-static\pch-off\lib1-2.obj...
> ...skipped <pbin\msvc-10.0\debug\link-static>lib1.lib for lack of
> <pbin\msvc-10.0\debug\link-static\pch-off>lib1-1.obj...
> ...failed updating 2 targets...
> ...skipped 1 target...
> ...updated 17 targets...
>
> -------------------------------------
> The second time the lib2-2 is already generated and the build succeeds.
>
> C:\Users\George\generator\test>b2 link=static lib1
> ...found 49 targets...
> ...updating 5 targets...
> jamcompil.generate bin\msvc-10.0\debug\link-static\pch-off\lib2-2.cpp
> compile-c-c++ bin\msvc-10.0\debug\link-static\pch-off\lib1-1.obj
> lib1-1.cpp
> compile-c-c++ bin\msvc-10.0\debug\link-static\pch-off\lib1-2.obj
> lib1-2.cpp
> msvc.archive bin\msvc-10.0\debug\link-static\lib1.lib
> ...updated 5 targets...
>
> Note that the problem is reproducible for some reason only on windows.
> It is probably based on difference in the targets order.
>
> Thanks,
> George
>
>
>
>
>
>
>
> On Wed, Mar 21, 2012 at 11:13 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>> AMDG
>>
>> On 03/21/2012 08:49 PM, George Georgiev wrote:
>>> <snip>
>>>
>>> The generated header files repeat the dependencies from the compil
>>> files, or in our case this will mean that b.h will have #include
>>> "a.h". And this is where the current generator fails. It does not
>>> track the fact that b.cpp includes  a.h indirectly because b.h
>>> includes a.h. This results in the jam build to execute the b.cpp
>>> compilation before a.compil to be (re)generated. This results in
>>> compilation error or b.cpp build against outdated a.h depending on is
>>> the build is initial or incremental.
>>>
>>> To make the case even more complex the compil files could have
>>> circular dependencies.
>>>
>>>
>>> I tried another build systems and they are unable to handle well the
>>> complexity of my case. It looks like Boost Build has the potential to
>>> do it, but it seems that it requires some time to be spend with it
>>> before to be able to develop for it. If some of the more expirenced
>>> guys in the group is willing to help me with this I can send you the
>>> project on you personal email - it is 123MB compressed.
>>>
>>
>> That's a bit much for email.  I'm attaching
>> a version that tries to capture the key
>> elements of your problem.  (To run this
>> generator/compil must be in BOOST_BUILD_PATH).
>>
>> The problem is that <implicit-dependency> is
>> required when files in one main target include
>> headers generated by another main target.
>> (This is unfortunately an unavoidable
>> consequence of Boost.Build's target model)
>> What you'd like is for everything to have an
>> <implicit-dependency> on everything else.
>> Ideally, you'd like to write
>>
>> project : requirements <implicit-dependency>$(all-libs) ;
>>
>> Unfortunately, this create circular dependencies
>> that Boost.Build can't resolve.  The trick to
>> solving this is to split up compilation into
>> separate steps:
>>
>> for local f in $(files)
>> {
>>    cpp $(f).cpp : $(f).compil ;
>>    obj $(f).o : $(f).cpp : <implicit-dependency>$(files).cpp <pch>off ;
>> }
>>
>> Now, all the object files can find all the
>> headers, and the #include scanner takes
>> care of the rest.  This is a bit of a pain,
>> but I don't think it's possible to do better.
>> I did test this and it seems to work. Running,
>>  b2 link=static lib1
>> works correctly.  Note that lib1-1.compil
>> imports lib2-2.compil, so lib2-2.cpp is
>> built.  lib2-1.compil is not referred to
>> by lib1, so lib2-1.cpp is not built.
>>
>> In Christ,
>> Steven Watanabe
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>>