Using Unsermake

The KDE-svn ebuilds have unsermake support now. If you don't know what unsermake is: unsermake is a replacement for automake.

unsermake is now used by default to build KDE. To disable it emerge with the environment UNSERMAKE=no

If you manually want to build KDE apps with unsermake, you must call unsermake directly instead of make:

make -f Makefile.cvs / Makefile.common
./configure
unsermake
unsermake install

If you set FEATURES="keepobj" in your /etc/make.conf or your environment, whenever a package is merged, its compiled files will be saved. When a new merge is attempted, only the files modified on the SVN repository will be compiled.

Additionally, you may add confcache to your features, which will speed up the configure script by saving a cache of results.

By default, the directory where the compiled objects are stored is /var/tmp/portage/objects, but you may modify it, by setting PORTAGE_OBJDIR in your make.conf or your environment.

NOTE: if you switch between automake to unsermake, dependencies may not be handled correctly and everything may be recompiled

KNOWN PROBLEMS: for unknown reasons, sometimes some compiles are performed in the install stage and they usually bomb out. The only remedy right now is deleting their corresponding folder in the objects directory. I hope I will sort this out sooner or later.

"autoskipcvs" is a feature we provide for the kde-svn ebuilds (and those only). If you enable it, those ebuilds will first check for newer revisions on the SVN server for the package and then only proceed if there is in fact a newer revision. This way, you can in fact queue all KDE apps for emerge, but only those with newer svn revisions will get updated, and you will save a lot of compile time this way.

Like all other FEATURES, you can specify them in make.conf:

FEATURES="autoskipcvs"

We don't advise enabling it this way. Best is to pass it along on the command line, to prevent weird behaviour ;)

FEATURES="autoskipcvs" emerge


Questions and answers

Q: Why name it autoskipcvs when it only applies to svn ebuilds ?

A: Well, because there already is a keyword related to cvs/svn ebuilds in portage, named autoaddcvs, so in the spirit of consistency we decided to call it autoskipcvs. By the way, it's not that cvs ebuilds will never be supported by this feature, We just haven't got around to it to implement it in the cvs.eclass. So be patient.

Q: When I emerge a list of packages, emerge stops at the first not-updated package ?

A: Yes. That's "normal" behaviour. I did not find a way to make the ebuild quit graciously so I made it quit with an error. If I don't do that, ebuilds that did not compile anything will get merged to the live filesystem, but nothing has been compiled so you will find no executables installed, and that's not a good thing.

A quick workaround is to use a BASH "for" loop to emerge a list of KDE apps:

list="app1 app2 app3"; for i in ${list}; do emerge "${i}"; done

Q: Some package haven't been updated for a long time

A: You have to be cautious about the order in which KDE apps are updated. All the source is kept and updated in the same place, which can lead to package A being updated from SVN for package B, but not being compiled and installed. Take a look at the script (scripts/updateKDEsvn), it uses autoskipcvs and you will notice it doesn't randomly merge packages after each other, there's an order, so that package A is indeed updated before package B.

To give you a more understandable example, kde-base/kcontrol also fetches the code for kde-base/kicker and kde-base/kdm (among others). So if you run

emerge kde-base/kcontrol kde-base/kicker kde-base/kdm

kicker and kdm do NOT get updated, because the local svn copy is the newest revision. Be aware of that.