This is going to be a meta bug that lists all of the ebuilds that ignore distcc (for whatever reason).
*** Bug 25677 has been marked as a duplicate of this bug. ***
So far, from bug 25677 app-text/openjade-1.3.2-r1 media-libs/gle-3.0.1-r2 x11-misc/xscreensaver-4.11 gnome-base/ORBit-0.5.17 app-arch/zip-2.3-r2
openjade, zip and gle were fixed. They just needed a s/make/emake in src_compile(). ORBit has a note in the ebuild about "-j4 not working" so I won't touch that one.
kdemultimedia-3.1.3 is also not using distcc
kdepim-3.1.3 is another one.
x11-base/xfree-4.3.0-r2 (maybe other versions as well) As far as I understand this is due to the stripping of unsafe flags by the ebuild: lines 16-36 of xfree-4.3.0-r2.ebuild
ARGHHH!! compiling XFree and KDE on a PII-233mhz machine.. I'm really bugged that I have to select an older version of XFree to compile it within a day (using distcc) - it's reaaaaaaaly slow going on localhost only :( How are you doing with fixing this xfree ebuild? and what are the flags that make gcc use distcc? I'd like to know - then I could try and fix the ebuild my self (forcing those flags to not be cleared) and see if it still works..
There are comments inside the xfree .ebuild that explain why it fails with parallel builds. Its an upstream Makefile problem, essentially.
ffmpeg 0.4.7_pre20030624 As far as I could tell (by observing progress through top), this ebuild does not use distcc.
transcode 0.6.6 Same problem as ffmpeg Is it safe to assume that if an ebuild uses 'make' instead of 'emake', then it won't utilize distcc? Is it also safe to assume (in general with some exceptions) that making the change s/make/emake will fix this?
Yeah. If an ebuild doesn't use emake it won't follow MAKEOPTS. Usually its safe to just s/make/make/, but check bugzilla first for parallel build problems, and test it first.
Samba also appears to ignore distcc. The ebuild does indeed use make instead of emake, and I couldn't find any bugs about parallel-building samba ... in a bit, I'll get a chance to try the ol' s/make/emake.
Yep ... I just changed all the makes to emakes (5 in total) in the .ebuild, and it compiled happily.
Where ebuilds have an issue with parallel builds, it would be better handled by removing the -j option in MAKEOPTS (or setting -j1), rather than disabling distcc entirely avoiding emake. distcc can be useful for passing compiles off to a faster host from an old machine, used say as a firewall. The alternative, building binary packages elsewhere is much less convenient (temporary USE & CFLAG changes on build machine).
unixODBC also ignores distcc
openldap alos ignores distcc.
glib also ignores distcc
perl-tk seems to ignore distcc, it inherits from perl-module which uses make not emake. Will fixing /usr/portage/eclass/perl-module.eclass break other perl things?
media-tv/mythtv and media-tv/mythfrontend also ignore distcc
openssl seems to ignore distcc
x11-libs/gtk+-2.2.4 seems to work with s/make/emake and MAKEOPTS="-j7"
I think this can be closed. Some of these KDE things I have no chance to install since I don't have unlimited disk space to install KDE. Refile any existing problems and assign them to the proper folk, cc me.
see comment 22
Open Office actually ignores distcc when building from source. It took me 8 hours to compile. I looked at the activity on my distcc helper and there was no activity from distcc at all.
