[PyKDE] Root vs. non-root builds

[Jim Bublitz]

On 23-Aug-02 Steve Simmons wrote:
> I find the PyKDE/PyQt/sip insistance on being *built* as root
> disturbing. Yes, it's a bit easier to build as root than as a
> user, but only a bit.

Ahh - a chance to expound on the PyKDE build system!
(Sorry guys, but the more I type the less I smoke and I'm trying to
quit)

There are a number of inter-related factors in the build system:

1. It's easier (in terms of BW, patches, packaging, other stuff) to
distribute PyKDE as .sip files instead of .cpp files. 

2. With GNU tools (the traditional ./configure make su make install)
(1) becomes very kludgy and the GNU tools are incompatible from
version to version (not to mention an extra few hundred K of code).

3. The solution to (2) is tmake/qmake plus some Python code to
establish the configuration (build.py)

4. To reduce the compile time from an hour to under ten minutes
(over 80% reduction) we concatenate all of the cpp files generated
by sip into a single huge file (thanks to Debian for the idea).

(3) and (4) are potential problems for users, since PyKDE's build
system is only tested (by me) on a single platform (SuSE). It's
probably not rocket science, but there are a lot of details to the
build system, so my current goal is simply to get it working and at
the same time try to keep up with the KDE release schedule. So far
it seems to work very well - one major bug in some code I stole
from Phil's (sip/PyQt) build.py because Qt 3.0.5 change versioning
after I had my code 'written'.

So why do you need to be root to run make in this system? I
actually haven't looked that far yet, being pleased just to have
the whole thing working. I suspect it's because the 'all' target 
(the one 'make' runs) in the module-level Makefiles includes the
target that performs the deletion of old libs and
copy-to-destination of new libs, and the destination directory is
owned by root and only root has write privileges there (as it
should be). I only think this because someone asked a question here
a day or two ago which led me to look at the Makefiles and form the
impression that that is in fact the case. I haven't looked any
further, and might still be wrong about that.

The Makefiles are structured this way not because I chose to write
them in this fashion, but because tmake/qmake generate the
Makefiles in this fashion. To fix the problem, I have to edit the
Makefiles after tmake/qmake generate them, but the Makefiles don't
exist until the end-user runs the build.py script. Maybe this will
be an easy fix to build.py (to edit the generated Makefiles
automatically) and maybe it won't.

The benefit of approaching the build system incrementally is that
there is one less piece of code to worry about at the present, so
it's more likely to work (which seems to be the case) and users get
to upgrade KDE more quickly (important since KDE 3.0.3 includes
real security patches) - which is also the case, since the release
went out today.

While I'm not happy with requiring root privs to run make for
PyKDE, I don't think it's the end of the world. I'd like to fix it
for the next release or the one after that *after* I feel any other
potential problems with the build system have either not occurred
or have been resolved.

>   o  How can we modify the build/install mechanisms to avoid
> root.

You can certainly edit the Makefile after build.py has run to
completion, or you can edit build.py and submit a patch. You might
also temporarily change the privileges on python/site-packages and
wouldn't need to be root ever (I'm guessing) except to change the
privileges of course.

>   o  Is anybody else interested.

I'm interested and will get to it eventually. In the scheme of
things (which includes 3 other major projects at the moment, one of
which "pays the bills" for the time I spend on PyKDE), it just
doesn't feel that important to me - not important enough to delay
the last two releases and not important enough to be a top priority.
I really don't like it (the su before make causes me other
problems), but I don't think it's that big a problem for most users
as long as you remember to type 'exit' after 'make install'
completes.

OTOH, the tarballs have dropped from 3MB+ to under 600KB (Phil pays
for the bandwidth) and from one tarball per version to one tarball
for all versions. The compile time, as noted, is 80% less for most
users. And, in a previous message, I could suggest edits to you to 
fix a problem as opposed to having to generate a complete new
tarball (which was the situation in the past). I don't mind running
make as root for a short time for those kinds of improvements.

Damn! I still have 70 minutes to go 'til the next cigarette.


Jim