function/object naming scheme

[Ralf Habacker]

Holger Schröder schrieb:

>Hi all,
>
>On Thursday 29 December 2005 17:57, Ralf Habacker wrote:
>  
>
>>Hi all,
>>
>>the recent bksys implementation provides functions with different naming
>>notation like
>>
>>env.bksys_install
>>env.CreateFile
>>env.KDEicon
>>env.qt4obj
>>
>>which is irritating, so I like to know if there are some preferences or
>>rules already available or prefered ?
>>
>>    
>>
>i think when we have a working kdelibs or at least a big part of it, we should 
>have a look at the sconscript files again and think about what should be 
>there and what is redundant/too complex and so on. and then we can revise the 
>syntax of these files too.
>  
>
My initial intention for this thread was to get some overview into the 
bksys api especially relating to your new install functions, which seems 
to be required also in kdelibs. Merging them into bksys should not to be 
moved to late in the future.

>but before we do that i would recommend that we get the basic apps not only 
>compiling but working too, so that we can spot the problems, that are still 
>ahead.
>  
>
The first step I see is to make sure, that mostly of the kdecore, kdeui 
and kio test applications are running. They gives more finer control 
about what is tested and what not. The question currently is which tests 
applications are really required.

>i started doing this. i tried to compile and run the katetest program from 
>kate. it already involves quite some kde "components". it has a gui composed 
>by xmlgui, uses kioslaves for loading and saving files, it loads the katepart 
>into the mainwindow, ...
>
>  
>
this seems to me second step

>on thursday i found this problem, when i tried to run katetest:
>
>--- trunk/KDE/kdelibs/bksys/kde4.py #492402:492403
>@@ -75,8 +75,10 @@
> 
>                dest=open(env.join(env['_BUILDDIR_'], 'config-kde.h'), 'w')
>                dest.write('/* kde configuration created by bksys */\n')
>-               if env.has_key('LIBSUFFIXEXT'):
>-                       dest.write(('#define KDELIBSUFF "%s"\n') % 
>env['LIBSUFFIXEXT']);
>+               # FIXME what is this for ??? lib / lib64 <-> .so ???
>+               #if env.has_key('LIBSUFFIXEXT'):
>+               #       dest.write(('#define KDELIBSUFF "%s"\n') % 
>env['LIBSUFFIXEXT']);
>+               dest.write(('#define KDELIBSUFF ""\n'));
>                dest.close()
>                env['_CONFIG_H_'].append('kde')
>                
>
>and i have no idea, if there are still more things wrong like this.
>
>before that patch, katetest did not even display a main window, but it only 
>crashed. after that fix it showed te attached window(screenshot):
>
>so i propose the following mini-roadmap:
>
>  
>
1a. make mostly of the kdecore, kdeui and kio test applications first 
under unsermake than under scons running.

>1b. make katetest under scons work as much as the unsermake version.
>(this means make xmlgui work with scons, and then search for more bugs, or be 
>happy that it works)
>  
>
>2. make background colors under unsermake work, it seems they are all black 
>now...
>  
>
under windows this is a problem too

>3. fix the other components that still not work. perhaps test shortcuts, 
>opening a new katetest window, load a remote file, test, if dcop stuff works 
>as expected, and so on.
>4. now from this state we know what works under scons under linux, and we can 
>go on under windows, and we know, that katetest works, and problems under 
>windows should then be "scons under windows"-related, and not "scons vs. 
>unsermake"-related.
>
>5. when katetest under windows runs: have a party!!!, as this would be quite a 
>big milestone on the road to a working kdelibs under windows.
>
>6. update this roadmap ;-) from here, we know, which problems we had to fix, 
>and we know finally, which things must be in the sconscript files and the 
>bksys subdir. i expect problems especially when loading kparts under windows 
>and so on.
>  
>
BTW: katetest compiles now out of the box from svn.

Ralf