Re: Questions About the New Schedule

Hello all,

Sebastian Kügler wrote:
> On Monday 01 October 2007 10:37:06 Andreas Pakulat
wrote:
>> On 01.10.07 06:30:25, Dirk Mueller wrote:
>>> On Saturday, 8. September 2007, Albert Astals
Cid wrote:
>>>>> 5)  Should language bindings be part of
the development platform?
>>>>> Richard Dale says "Python and Ruby
in good shape by late October, and
>>>>> possibly C# too."
>>>> If Richard says he can do it, i say we can
try it 
>>> Thats not enough. somebody has at least to be
able to confirm that the
>>> bindings *compile*. right now, kdebindings does
not compile, and after I
>>> spent an hour or so looking, I'm sure that it
can not compile for anyone
>>> at all, given the fundamental bugs in the build
system.
>>>
>>> it is my understanding that Richard uses a
completely different build
>>> system to maintain the bindings, at least thats
what he used to do in
>>> KDE3 times. There has to be at least somebody
who maintains the official
>>> build system, and that person has to be != me.
>> Same thing applies to the python bindings, but
those are not buildable
>> with cmake and I don't see why they should be.

> I understand that Simon Edwards is working on making
them compile with cmake. 
> Simon, can you give us an update about the python
bindings? How stable are 
> they? 

I don't remember telling anyone other than Jim Bublitz that
I was 
looking at using cmake to build the bindings. But as a
matter of fact, 
yes, yes I have been working on that for the last few days.
 (Am I

that predictable?) Until that is in order, the configure.py
script works 
ok. configure.py doesn't really handle installing things
other than the 
binding themselves (e.g. example code, docs etc). Which is
why I hope to 
be able to switch to cmake sometime as that will make it
easier for 
other people to build and install it all, and I'll be able
to recycle 
the cmake code which is already used in KDE.

As far as the bindings themselves are concerned, the kdelibs
stuff is in 
good shape except for one omission, Phonon. It is tricky
module to wrap 
and Jim has been working on it, although we might require
additions and 
fixes to SIP (bindings generator, produced and maintained by
Phil 
Thompson at Riverbank computing). Jim is still quite
confident to still 
have Phonon in KDE 4.0. The other modules in kdelibs are
definitely 
complete enough and stable enough for people to develop on.

Other things like docs, example code, test code, and other
things which 
you would expect in a SDK, are still being developed and
worked on. We 
expect to have it in order by 4.0. This might appear to be a
lot of 
development late in the KDE 4 process, but it is
unavoidable. We needed 
a relatively stable and workable kdelibs before the real
bindings work 
could even start. That said, the bindings themselves are
very solid. The 
tools which we are using and building on, SIP and PyQt, have
been in 
production for at least 18 months now.

On a technical level, what can I provide in the build system
for the 
Python bindings which would simply the tarballing stage of
release work? 
(directory layout? a special build target "make
dist"??)

cheers,

-- 
Simon Edwards             | KDE-NL, Guidance tools, Guarddog
Firewall
simonsimonzone.com       | http://www.simonzo
ne.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right
choice."
_______________________________________________
Kde-bindings mailing list
Kde-bindingskde.org
ht
tps://mail.kde.org/mailman/listinfo/kde-bindings

On Monday 01 October 2007, Simon Edwards wrote:
> Hello all,
>
> Sebastian Kügler wrote:
> > On Monday 01 October 2007 10:37:06 Andreas Pakulat
wrote:
> >> On 01.10.07 06:30:25, Dirk Mueller wrote:
> >>> On Saturday, 8. September 2007, Albert
Astals Cid wrote:
> >>>>> 5)  Should language bindings be
part of the development platform?
> >>>>> Richard Dale says "Python and
Ruby in good shape by late October, and
> >>>>> possibly C# too."
> >>>>
> >>>> If Richard says he can do it, i say we
can try it 
> >>>
> >>> Thats not enough. somebody has at least to
be able to confirm that the
> >>> bindings *compile*. right now, kdebindings
does not compile, and after
> >>> I spent an hour or so looking, I'm sure
that it can not compile for
> >>> anyone at all, given the fundamental bugs
in the build system.
> >>>
> >>> it is my understanding that Richard uses a
completely different build
> >>> system to maintain the bindings, at least
thats what he used to do in
> >>> KDE3 times. There has to be at least
somebody who maintains the
> >>> official build system, and that person has
to be != me.
I use cmake to build the smoke libs and the ruby and python
bindings, and it 
all works fine. I'm afraid I can't reproduce the perl error
that the 
dashboard build has. 

http://ktown.kd
e.org/~dirk/dashboard/

I just did a diff from the kalyptus code as it was in 2004,
and how it is 
today and the line with the error is much the same:

 -226,17
+217,18 
 # Otherwise, compile the default ones. Used for filtering
in readCxxLine.
 if ( my qt_defines = map { ($_=~m/^QT_(.*)/)[0] } keys
%defines)
 {
-    my $regexp = "m/^#\s*ifn?def\s+QT_(?:" .
join('|', map 
{ "$qt_defines[$_]" }
0..$#qt_defines).")/o";
+    my $regexp =
"m/^#\s*if\s*[n!]?\s*def(ined\()?\s*QT_(?:" .
join('|', 
map { "$qt_defines[$_]" }
0..$#qt_defines).")/o";
     $match_qt_defines = eval "sub { my $s=shift;
-                                   $s=~/^#\s*if(n)?def/
|| return 0;
+                                  
$s=~/^#\s*if\s*([n!])?s*def(ined\()?
\s*QT_/ || return 0;
                                    if(!$1) { return
$s=~$regexp ? 0:1 }
                                    else { return
$s=~$regexp ? 1:0 }
                                   }";
+
     die if $;

I couldn't understand the perl in 2004, and I don't really
understand it now. 
Certainly lots of people have run kalyptus to build the
smoke bindings, and 
only dashboard has this error:

Global symbol "$qt_defines" requires explicit
package name at (eval 1) line 4.
Global symbol "$qt_defines" requires explicit
package name at (eval 1) line 4.
Global symbol "$qt_defines" requires explicit
package name at (eval 1) line 4.
        ...propagated at
kdebindings-717467/kalyptus/kalyptus line 227.
make: *** [smoke/plasma/smokedata.cpp] Error 255
make: *** [smoke/plasma/CMakeFiles/smokeplasma.dir/all]
Error 2
make: *** [all Error 2

This is the code that is failing:

# Check the %defines hash for QT_* symbols and compile the
corresponding RE
# Otherwise, compile the default ones. Used for filtering in
readCxxLine.
if ( my qt_defines = map { ($_=~m/^QT_(.*)/)[0] } keys
%defines)
{
    my $regexp =
"m/^#\s*if\s*[n!]?\s*def(ined\()?\s*QT_(?:" .
join('|', 
map { "$qt_defines[$_]" }
0..$#qt_defines).")/o";
    $match_qt_defines = eval "sub { my $s=shift;
                                  
$s=~/^#\s*if\s*([n!])?s*def(ined\()?
\s*QT_/ || return 0;
                                   if(!$1) { return
$s=~$regexp ? 0:1 }
                                   else { return
$s=~$regexp ? 1:0 }
                                  }";

    die if $;
}

Would it help to move the 'my qt_defines' outside the
'if' statement? Without 
being able to reproduce the bug, this is impossible to fix
for me.

my qt_defines;

if (qt_defines = map { ($_=~m/^QT_(.*)/)[0] } keys
%defines)
{

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindingskde.org
ht
tps://mail.kde.org/mailman/listinfo/kde-bindings