Bugzilla Bug 18183

The attached ebuild is for the recently released version 1.30 of the free C++
library boost (boost.org).

Created an attachment (id=9808) [edit]
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 an attachment (id=11328) [edit]
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 an attachment (id=11340) [edit]
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 an attachment (id=11397) [edit]
Detects/uses icc to build if present

Created an attachment (id=11398) [edit]
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 [edit] has a missing "\" on line 56. Otherwise builds fine.

Created an attachment (id=11918) [edit]
(v3)

Adds missing '\'

Created an attachment (id=12081) [edit]
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 ;)