Bugzilla Bug 79517

Along with boost.python, boost also has a nice python interface generator
called pyste.  Right now pyste isn't being installed because it's optional. 
Doing so is fairly simple, however, since it's just a matter of cd'ing into
boost's libs/python/pyste directory and running python setup.py properly. 
Pyste is incredibly small compared to the rest of boost, so I don't see any
real reason to make it optional, but I'll happily leave that up to you.

Ah, perhaps a use flag might be a good idea.  Running pyste requires
elementtree and gccxml as dependencies.  I just added gccxml to portage.

once i find out why it isnt possible to build boost's own serialization
demo.cpp albeit built by bjam ill add that, i just dont want to add something
to the mix before that, plus the constant bugging about either not wanting
-toolset- in lib name or do wanting it looks like another USE flag too, again,
after i find out why it isnt built properly using bjam (which was the #1
suggestion on making sure our boost is built right "use bjam")

ok, wanna tell me how to run setup.py properly ill add the deps and local pyste
useflag

the link issues relate to binutils and serialization only coming in .a flavor,
with that sort of cleared id like to see to get this done, i dont know pyste,
so ill need you to clue me in :)

Created an attachment (id=54115) [edit]
boost.patch

i will see to incorporate this into all the other changes boost will receive by
-r2, although the patch offsets   wont be right i think i can handle putting 
this in "manually"

once i get some replies to me USE flag thread on -dev ML i'll be able to
commit, including this, thanks

It's actually quicker to patch the new ebuild, let the IUSE and RDEPEND hunk
fail, and just fix that hunk by hand.  Less typing that way!

please test http://dev.gentoo.org/~morfic/boost-1.32.0-r3.ebuild

hm, there is a pyste.py now in my path :)

dev-cpp/gccxml and dev-python/elementtree need keywording for ~sparc ~ppc64
~ppc ~amd64 for this to become a reality

i will do the ~ppc testing right now (cmake seems distcc unfriendly), and hope
for some ~amd64 (in a couple days) action while i do this, i would have to drop
keywords if the testing can't happen, which i wouldnt like doing

down to sparc, ppc64 and ppc-macos dep loving

any complaints about the ebuild from your side?

well of course i would use.mask pyste on spark and ppc64 not drop them
alltogether, no  idea what i was thinking there

pyste now can be installed with boost if so wished