Summary: | Installing pyste w/ boost | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Grant Goodyear (RETIRED) <g2boojum> |
Component: | [OLD] Development | Assignee: | Disenchanted (RETIRED) <morfic> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | boost.patch |
Description
Grant Goodyear (RETIRED)
2005-01-25 14:38:47 UTC
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! 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 |