dev-util/cmake-2.4.7-r2 (currently p.masked) depends on >=dev-libs/xmlrpc-c-1.06.03 now. Until -r1 the bundled xmlrpc-c (and lots of other bundled stuff) was used. As xmlrpc-c obviously built on your arches before as a part of cmake, keywording this should not be a big deal. :-)
cf. comment #1. Actually CC'ing arches probably helps a lot... :)
If newer cmake requires xmlrpc-c, why does xmlrpc-c-1.10 require cmake to build? That's a big chicken and egg isn't it? This is obviously a problem for users who don't currently have cmake installed.
(In reply to comment #2) > If newer cmake requires xmlrpc-c, why does xmlrpc-c-1.10 require cmake to > build? That's a big chicken and egg isn't it? Not really as 1.10.0 is p.masked, doesn't have the necessary DEPEND on cmake so that it wouldn't install anyway for users without cmake (which if, of course, a bug) and it doesn't even need cmake as it is autotools-based as per upstream. Even the newer 1.11.0 (the last version released as tarball) has no official cmake support nor has current SVN (which is the new "release method"... *sigh*) at the time of writing (and the code has last changed only 4 days ago). I consider 1.10's "experimental cmake patch" a dead end. To better reflect this, I've updated the summary and I'm CC'ing xmlrpc-c's maintainer. Benedikt, do we need 1.10 in its current form for anything? It's been p.masked for more than four months.
I think it's better to specify an exact version in the Summary: the target appears to be =dev-libs/xmlrpc-c-1.06.03 or _preferably_ =dev-libs/xmlrpc-c-1.06.09
bsd done
Marked ~hppa.
(In reply to comment #2) > If newer cmake requires xmlrpc-c, why does xmlrpc-c-1.10 require cmake to > build? That's a big chicken and egg isn't it? > > This is obviously a problem for users who don't currently have cmake installed. > Suggestion: If a CMake buildsystem for xmlrpc-c becomes the only option, add a USE=internal-libs or similar to dev-util/cmake. Make it build CMake using the internal supplied libs. I'm not sure about the best way to let the user know that they have to do a USE=internal-libs emerge -1 cmake && emerge cmake, though.
~ia64/~sparc done
added ~ppc64
ebuild issues: - pointless usage of arrays when a plain string will do fine (and could even be simplified beyond needing myconf at all) - no quoting of $D in src_install - not using emake in src_install - does this package really come with no files you can `dodoc` on ?
(In reply to comment #3) > Benedikt, do we need 1.10 in its current form for anything? It's been p.masked > for more than four months. Well, xmlrpc-c's build system is horribly broken, therefore i added the patch. But honestly, i have no interest in this crappy library anymore. the buildsystem sucks, the api is awful and with every new release it breaks even more. therefore i will update metadata to maintainer-wanted and mail -dev asap.
(In reply to comment #11) > therefore i will update metadata to maintainer-wanted and mail -dev asap. No need to write that mail - just add me to metadata.xml, please. I'll take it.
done, thx.
(In reply to comment #10) > ebuild issues: > - pointless usage of arrays when a plain string will do fine (and could even be > simplified beyond needing myconf at all) Well, this bug was not about 1.10.00 in the first place. :-) > - no quoting of $D in src_install > - not using emake in src_install > - does this package really come with no files you can `dodoc` on ? These issues have been fixed now.
sorry for the delay ... i did test but forgot to actually commit keywords btw, it seems -O3 gets forced into the build irregardless of user's flags ... you may want to fix that ;)
Fixed. Thanks, vapier! :-) mips, I'm dropping your keyword on cmake-2.4.7-r2 and will file a new bug for re-keywording.
xmlrpc-c-1.16.06 has ~mips keywords.
