Proposal for KDE 4.0

[Michael Pyne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 18 August 2004 01:34, David Johnson wrote:
> Except that it doesn't necessarily do away with the very awkward command
> line. Granted, the user isn't likely to be typing this in by hand, but
> it still makes an examination of a build log that much more painful on
> the eyes.

Here's a sample compilation command line that we have now (generated by the 
configure script used to build KDE PIM):
g++ -DHAVE_CONFIG_H -I./kitchensync/kitchensync/lib 
- -I/home/kde-cvs/kdecvs/kdepim/kitchensync/kitchensync/lib -I. 
- -I/home/kde-cvs/kdecvs/kdepim/kitchensync/libksync 
- -I/home/kde-cvs/kdecvs/kdepim/kitchensync/libkonnector2 
- -I/home/kde-cvs/kde/include -I/home/kde-cvs/kdecvs/build/qt-copy/include 
- -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -D_FILE_OFFSET_BITS=64 
- -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 
- -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W 
- -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -Os -g -pipe 
- -march=athlon-xp -fvisibility-inlines-hidden -Wformat-security 
- -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common 
- -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT 
- -DQT_NO_TRANSLATION -fPIC -DPIC 
- -c /home/kde-cvs/kdecvs/kdepim/kitchensync/kitchensync/lib/actionmanager.cpp 
- -o ./kitchensync/kitchensync/lib/.libs/actionmanager.o 
- -Wp,-MD,./kitchensync/kitchensync/lib/.deps/actionmanager.TUlo

I would dare say that this is much much more awkward than any command line 
pkg-config would make us use.  But let's say that we were typing in a command 
line by hand.  Explain how this is awkward (this is a sample only):

g++ -o small-program `pkg-config --libs --cflags qt-4 kdelibs-4` *.cpp

What I've had to use for my own small test program that I don't want to import 
an /admin for was:

export QTDIR=~/kde-cvs/build/qt-copy
export KDEDIR=~/kde-cvs/kde
g++ -o small-program -I$KDEDIR/include -I$QTDIR/include -L$KDEDIR/lib 
- -L$QTDIR/lib -lqt-mt -lkdeui -lkio *.cpp

So as an actual "user who occasionally types in their own command line", I 
would MUCH MUCH MUCH prefer the pkg-config proposal.

Assuming that we end up using pkg-config, this could also make the configure 
checks for KDE programs significantly simpler.

> Since KDE releases are much more "synchronous" and unified than the
> GNOME style, the need for this kind of namespace versioning is much
> less. I don't imagine many users will want to mix and match KDE
> components across major versions. If they really want to, or in the
> case of a migration, installing under different hierarchies should be
> sufficient.

Well we're already getting into that.  KDE PIM 3.3, for example, AFAIK relies 
on kdelibs 3.2, not 3.3.  And just because it may be less common doesn't make 
it less useful.

I'm not sure what exactly Ali has in mind for his proposal.  e.g. versioning 
every app/lib, or just the modules, but I think it's clear that versioning at 
*least* the modules can be very useful.

Regards,
 - Michael Pyne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBIwC5qjQYp5Omm0oRArrEAJ4nFKyN4q0aUVlaIr0/cy3VTOQKGACbBr+d
Dwp8uWW6qgZ7yH3ziXcm0F8=
=YrW1
-----END PGP SIGNATURE-----