Re: [Boost-users] [boost 1.36]: Problems with bjam option --buildid

Subject: Re: [Boost-users] [boost 1.36]: Problems with bjam option --buildid
From: Daniel Krügler (dsp_at_[hidden])
Date: 2008-11-03 10:21:20

Vladimir Prus wrote:
> Daniel Krügler wrote:
> 
>> Vladimir Prus wrote:
>>> Daniel Krügler wrote:
>>>
>>>> Hello,
>>>>
>>>> a colleague of mine currently checks whether transition to
>>>> boost 1.36 (or upcoming 1.37) would be feasible for us.
>>>> Still being on 1.33.1, we manipulated the bjam files to
>>>> realize something that we hope can now be done with the build
>>>> option --buildid using the *non-manipulated* bjam files. A
>>>> recent test using the command line
>>>>
>>>> bjam --build-dir=XX --buildid=asdf --toolset=msvc
>>>> --build-type=complete stage
>>>>
>>>> where XX corresponds to a valid path causes a quick bjam build error
>>>> (but removing the part " --buildid=asdf" works fine), as shown
>>>> below. Let me add that the used bjam.exe was created based on the
>>>> sources provided by the very same boost 1.36 (build.bat).
>>>>
>>>> Does anyone have an idea what's going wrong here?
>>>>
>>>> Thanks & Greetings from Bremen,
>>>>
>>>> Daniel
>>>>
>>>> "warning: Graph library does not contain optional GraphML reader.
>>>> note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the
>>>> [..]
>>>> Skipping build of:  libs/python/build/boost_python  <build>no in common
>>>> properties
>>>> E:/sources/ntb/boost_1_36_0/tools/build/v2/build\virtual-target.jam:1032:
>>>> in virtual-target.register-actual-name from module virtual-target
>>>> error: Duplicate name of actual target: <pstage\lib>libexact.lib
>>> This is very strange. Does this error only happens with --buildid?
>>> Does this happen when building a single library (e.g. --with-program_options)?
>>> Do you think you can go to tools/build/v2/tools/stage.jam, find the copy-file
>>> rule, and, before the return statement, add this code:
>>>
>>>         ECHO "Name is" $(name) ;
>>>
>>> ? (BTW, we probably can solve this faster either on IRC (freenode, #boost), or via
>>> Skype (vladimir_prus)).
>> Unfortunately our IT center wont like that :-((
>> We can discuss details off-line, my e-mail address is:
>>
>> dan~stopper~iel.krueg~stopper~ler_at_goo~stopper~gle~stopper~mail.com.
> 
> We talked with Daniel via Gmail-Talk-does-not-care-about-firewall thing, and diagnosed
> the issue.
> 
> With buildid is specified, and layout is versioned, which is the default, the
> produced names are like this:
> 
>         stage/lib/libboost_program_options-mgw42-mt-1_37.so.1.37.0
> 
> Boost.Build automatically creates a link in the form
> 
>         stage/lib/libboost_program_options-mgw42-mt-1_37.so
> 
> And C++ Boost's Jamroot additionally creates this link:
> 
>         stage/lib/libboost_program_options-mgw42-mt.so
> 
> Now, if buildid is specified, the names are like this:
> 
>         stage/lib/libboost_program_options-mgw42-mt-1_37-xxx.so.1.37.0
> 
> and Jamroot code was buggy. Now the question is what symlink should be produced:
> 
>         stage/lib/libboost_program_options-mgw42-mt.so
> 
> or
> 
>         stage/lib/libboost_program_options-mgw42-mt-xxx.so
> 
> Daniel, you get to decide :-)

Hey, what an honor! ;-)

We do not work with symlink output, but personally I would suggest
to use the second approach, i.e.

stage/lib/libboost_program_options-mgw42-mt-xxx.so

Anyone preferring a different approach?

I would like to express my very thanks to Vladimir for his great
commitment to resolve this!

- Daniel