Version: 1.2.92 (using KDE KDE 3.1.3) Installed from: Compiled From Sources Compiler: GCC 3.3.1 OS: Linux It would be great if the configure script for KOffice tried to figure out Python's prefix directory, e.g. using PYTHON_DIR=`echo \`which python\` | sed "s|/bin/python||"` or something similar. This would be useful on systems such as mine where python is in /opt/python , as it saves yet another thing to edit on the configure commandline.
This is quite similar to this one -> http://bugs.kde.org/show_bug.cgi?id=61808 I am surprized that nobody ever told you to put export PYTHON_DIR=`echo \`which python\` | sed "s|/bin/python||"` in your ~/.bashrc ;-) This sounds more related to the packaging system (autoconf automake configure) than to koffice. I agree that this is not very user friendly, and that the tools should detect the right settings or warn the users (KDEDIR, JAVADIR ...). In addition the behaviour is not consistent : I've never seen ./configure complain about missing compiler (CXX not set) ;-)
Yes, this is very much along the same lines as your bug/request. Have you raised this issue on any mailing list? If not, I think I'll try and bring it to attention :)
I haven't talked about it on a mailing list. This problem is mostly related to autoconf and automake, it is not KDE or KOffice fault. If however you decide to raise this problem on a mailing-list, don't forget to mention the slowness of the configure scripts. When you install 10 programs ./configure has to detect each time the compiler, the libraries, the Qt location, etc. It could be a lot smarter and store the system-specific configuration parameters into a file (eg: feature an option eg :'--use-database' to use a configure-created database specific to your system). This is a problem for the developers as well, because configure is slow and giving the flags everytime to make sure it will compile is boring. Configure should be more configurable ;-)
I'm going to mark this bug as resolved, even though it isn't really, because it's the sort of thing that depends more on the distribution in use and/or autoconf. But if in future I can see any way of improving the situation I'll file another report.