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

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: 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@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