Or, have you figured out a way to get around that?
Well, we only extract the necessary files from the tarballs each time.
I guess there isn't a way to come up with some sort of portage hackery whereby the portage tmpdir doesn't get cleaned out until the last of the split ebuilds is merged?
Certainly not from the ebuild side. And the portage people were completely uninterested when I asked them long ago :-)
But it's an interesting problem. If the portage side provided eg readonly access to an unpacked kde source tree, the ebuilds could build everything out-of-tree. Or we could create a tree of hardlinks and build inside that, since we don't have write access to those hardlinks. (This speedup would apply to the monolithic ebuilds, too.)
I'd be willing to try implementing it if I was convinced that the unpacking was the main overhead introduced by increasing the amount of ebuilds. Right now the main overhead is running configure multiple times (how long does that take you?), so I want to see confcache get here first, and meanwhile work on other speedups like unsermake, and when all that's done I'll try out this idea.
One of our users timed ./configure last night, and it was in the neighborhood of 5 minutes if I remember correctly. So, unless the kde tarballs are split up into tiny chunks for each program, we're looking at 10 or more minutes of unpack+configure for each ebuild.
Steve
-- gentoo-dev@gentoo.org mailing list
