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 attachment 54115 [details, diff] 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
