The attached ebuild is for the recently released version 1.30 of the free C++ library boost (boost.org).
Created attachment 9808 [details] Ebuild
This bug is possibly redundant considering a previous submission of an ebuild for boost 1.30 (bug number 17995). I do believe, however, that this ebuild handles the documentation better than 17995. Specifically, the other ebuild uses the same method as is used in the 1.29 ebuild, and excludes certain documentation elements include xml, sgml, and example code files that are part of the documentation. - Jeremy Maitin-Shepard
*** Bug 17995 has been marked as a duplicate of this bug. ***
Yeah it does. I didn't bother looking at that part. Your ebuild works over here as well. Would be nice if it were added at least into unstable. hint hint. :)
Oh yeah: Had thought of separating bjam into a separate ebuild. It would also make it more visible.. and it's just, soo cool anyway. : ) Thoughts?
Yeah, I had thought of that also. I had simply not seen any other use for bjam, given that it does provide too many improvements over jam. On a related note, have you been able to figure out how to make bjam or jam use CLFAGS and CXXFLAGS? It did not appear that "-sGCC=${CC} ${CFLAGS}" "-sGXX=${CXX} ${CXXFLAGS}" has any effect despite the documentation. Another issue is that at least on my system, a few (like 5) of the targets fail in 1.30, so I had to remove the check on the return value. It is not clear what exactly these targets are, or whether they simply don't matter.
About the failures, I assume you're referring to this part at the end of the build process: ...failed updating 6 targets... ...updated 539 targets... I think they're Python related. If you disable Python support they go away. No idea where the failures are or why they trigger though. I'll see if I can do some snooping around with this one this weekend.
When you restart the build process it magically completes the previously failed targets. Weird. I ran into this on accident when trying to test the build time, like this: # ebuild boost-1.30.0.ebuild compile ...blahblah...blah ...failed updating 6 targets... ...updated 539 targets... # time ebuild boost-1.30.0.ebuild compile >>> Checking boost_1_30_0.tar.bz2's mtime... >>> WORKDIR is up-to-date, keeping... ### ### Using 'gcc' toolset. ### rm -rf bootstrap.gcc mkdir bootstrap.gcc gcc -o bootstrap.gcc/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c ./bootstrap.gcc/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 44 targets... ...found 3407 targets... ...updating 6 targets... FileClone libs/python/build/bin-stage/libboost_python_debug.so.1.30.0 FileClone libs/python/build/bin-stage/libboost_python.so.1.30.0 FileClone libs/regex/build/bin-stage/libboost_regex_debug.so.1.30.0 FileClone libs/regex/build/bin-stage/libboost_regex.so.1.30.0 FileClone libs/thread/build/bin-stage/libboost_threadd.so.1.30.0 FileClone libs/thread/build/bin-stage/libboost_thread.so.1.30.0 ...updated 6 targets...
Created attachment 11328 [details] new boost ebuild
Well, there's an updated ver with the doc updates and a trivial work around for the failures. I asked on the boost list if there was a cleaner way to build nicely without the cheap hack, but there was no response. No big deal anyway.
Created attachment 11340 [details] Updated ebuild (python version detection) I have added some perliminary automatic detection of python version. Basically, I use the following: python -V 2>&1 | cut -d . -f 2,3
I was thinking of doing something like that, ... but was hoping for some built-in eclass that provided it or something. Another thing that would be handy is access to MAKEOPTS, to pass to bjam.
Created attachment 11397 [details] Detects/uses icc to build if present
Created attachment 11398 [details] Detects/uses icc to build if present (v2) The last one was ill-formatted w.r.t. whitespace
Oh yeah, I noticed that the documentation mentioned has this example for passing optimization flags: -sBUILD="<cxxflags>/G6" via http://www.boost.org/tools/build/build_system.htm#initiating When I try adding something like "<cxxflags>-march=blah -O3" it builds a variant for each one of those flags. That doesn't seem right. Maybe it's just being stupid and only recognizes '/' for switches. Would like to figure that as well.
Ebuild in attachment 11398 [details] has a missing "\" on line 56. Otherwise builds fine.
Created attachment 11918 [details] (v3) Adds missing '\'
Created attachment 12081 [details] slightly modified ebuild Hi guys. So this was quite a hot bug ;), but I see it finally stabilized. I have checked the latest version and did few modifications. It tested out Ok with gcc, now attaching here to ask people to test it with icc. George
Ok, this has been tested by me and <mIGu> on #gentoo with icc as well. Committed to portage, please test. George
Works fine. Thanks George.
in stable already
1.30.2 in portage time to close ?
i think so ;)
