Boost Users :
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:
>>>> 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,
>>>> "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
>>>> 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:
> 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:
> Boost.Build automatically creates a link in the form
> And C++ Boost's Jamroot additionally creates this link:
> Now, if buildid is specified, the names are like this:
> and Jamroot code was buggy. Now the question is what symlink should be produced:
> 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.
Anyone preferring a different approach?
I would like to express my very thanks to Vladimir for his great
commitment to resolve this!
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net