Mailing List Archive

On Sunday 19 September 2004 21:33, Dan Armak wrote:
> As I said, I'm definitely going to try making this work, but won't have
> real time until the weekend after next (and most days after that,
> hopefully), so you can beat me to it.

There are other few issues, for example some libraries aren't installed in the
system because defined in the Makefile.am as "noinst_LTLIBRARIES". And some
programs in differents subdirs are linking to them, so these library must be
recompiled for every program we are compiling that needs them and this will
bring to more compilation time. I can't see a solution to this, installing
them will go against the kde developers decisions and there's a reason
because they aren't installed.


> I've just tried the confcache patch. It's integrated into portage .51 cvs
> snapshots here http://dev.gentoo.org/~ferringb/ebuild-daemon/51-pre20-cvs/
> - they apparently include other highly experimental stuff and the last one
> has some bugs already fixed in cvs, so be in touch with #gentoo-portage if
> using these. To enable confcache, add 'confcache' to FEATURES and change
> the kde ebuilds to use econf rather than call configure directly. This
> results in the kde.eclass attached - the change is trivial, but as I'm on
> rsync not cvs atm, I can't make a diff immediately, sorry. The change for
> split packages should also be on the order of a five-liner in kde.eclass,
> apart from the makefile changes.
>
> On my athlon xp 2600, this makes the kdelibs configure run go down from 66
> seconds to 28 seconds. At least 10-12 seconds of each of these two numbers
> is due to makefile generation, which will be very much reduced in split-up
> ebuilds, so we get 54 sec -> 16 sec, or a 5x improvement.
>
> Also, on slower machines a far larger percent of time spent in (non-cached)
> configure is due to slow compilations rather than (as here) IO, so the
> benefit will be even greater there. This indicates we should at least
> reevluate the emerge performance factor of splitting up the kde ebuilds.
>
> Using my old rough formula, we get:
> 17 configure scripts (before splitting ebuilds) --> 20-60 minutes total
> running time
> splitting up --> >=220 packages (? but at least that many, I believe)
> splitting up without confcache --> 220-660 minutes, i.e. 3.6-11 hours,
> total running time (clearly unacceptable)
> splitting up with confcache --> about 15-20% of above, i.e. 1-2.2 hours
> total running time
>
> According to these numbers, if we both add confcache and split the ebuilds,
> the total time for emerging all or nearly all of kde will increase by
> 0.6-1.2 hours, plus the overhead from running the emerge cycle 200 more
> times, which I hope is relatively negligible (a few minutes?).
>
> Compared with the benefits (to those who don't want all of kde, and
> considering that >95% of people typing 'emerge kde' to save package
> selection time don't really want kdetoys and kdeedu and such, this seems on
> first sight to be a reasonable tradeoff for the added functionality. What
> do you think, everyone? Also note that my benchmarking is hardly
> scientific, so I'd be glad if someone bothered to repeat it and compare his
> results to mine.
I'll try it. Thanks.

Bye!
---
Simone Gotti
<simone.gotti@email.it>
http://kde-bluetooth.sf.net

--
gentoo-dev@gentoo.org mailing list

I was thinking that is probably possible to make a bash script that will
automatically found what libraries name must be changed in the Makefiles.am.

So today I started putting down an initial script that will do this.
How and if it works is quite difficult to explain by now, because probably
there are corner cases that I haven't taked in account.

My idea is this:

1) This script will provide a function from ${PN} which is equal to the
subproject we want to compile, will modify the subprojects makefiles.
for example:

libkaddressbook_la_LIBADD =
$(top_builddir)/kaddressbook/printing/libprinter.la \
$(top_builddir)/kaddressbook/interfaces/libkabinterfaces.la \
$(top_builddir)/libkdepim/libkdepim.la -lkabc_file

will become:

$(top_builddir)/kaddressbook/printing/libprinter.la \
$(top_builddir)/kaddressbook/interfaces/libkabinterfaces.la \
-lkdepim -lkabc_file

like you can see in this way we will use the already installed (from a
previous "libkdepim" ebuild) libkdepim instead of compiling the local one.
libkabinterfaces.la can't be treated in the same way because is compiled when
we compile kaddressbook for the fact that is in the same subproject.

2) Create a list of the used subprojects, a subproject is equal to the first
kde-module subdir. kaddressbook don't need any other subproject, but for
example other programs will need a library defined like "noinst_LTLIBRARY"
and so unfortunately this can't be installed and must be recompiled for every
program that needs it. An example is libkcal that needs libical (and this is
a "noinst_LTLIBRARY" ).

3a) from this list we can remove the configure.in.in in the not needed
subproject, We can also remove the Makefiles.{in, am} and the recreate the
configure (and of course only the neede Makefiles.in).
Slow but quite right.

3b) create a list of DO_NOT_COMPILE
Fast but will leave some don't needed configure check. BUT I don't think this
will be a problem because of course the deps are already satisfied by the
deps of the subproject we are going to emerge.

Tomorrow I'll try to finish this script, implement it in an eclass and create
some simple ebuild to test them and if it works I'll post it and some
results.

Let me know what do you think about this idea.

Bye!
--
Simone Gotti
<simone.gotti@email.it>
http://kde-bluetooth.sf.net

--
gentoo-dev@gentoo.org mailing list