#1 PerlQt with KDE 3.0.7 on MacOSX

[Benjamin Reed]

I've modified the admin/ to include some fixes from the
KDE-Darwin tree, and rerun Makefile.cvs, which works fine.

I then ran configure and it gets most of the way
through (it seems), but dies with:

EXPORT_DOCKCLASS::~KDockTabGroup has no case \ number for sig=~KDockTabGroup() at \ kalyptusCxxToSmoke.pm line 1949.

(all on one line, but SF is notorious for formatting
these things weirdly)

Can I assume this is just a KDE 3.0.7-ism?

Is it possible to update the kalyptus in the tree from
KDE cvs without messing anything up?

[germain garand]

Logged In: YES
user_id=145773

Hi,
This is strange : it looks like kalyptus is parsing KDE
headers, not just Qt headers...
Remember this is PerlQt, not yet PerlKDE ;)

Is it possible that your Qt headers would be mixed with
KDE's in the same directory ?!?
We didn't think about such a case... we would then need to
setup a /^q.*/ regex on the header list in
/smoke/qt/generate.pl.in

You don't have to update kalyptus, since the version in
PerlQt is perfectly in sync with KDE CVS.

G.

[Benjamin Reed]

Logged In: YES
user_id=375

Ahh, yes, that could do it if you're parsing every header in
$QTDIR/include. Our build uses qt with a make install into
our normal tree, so $QTDIR=$KDEDIR=$PREFIX.

If you're reading that dir raw you're getting a bunch of
other unrelated headers too, I'm betting. =)

[germain garand]

Logged In: YES
user_id=145773

> so $QTDIR=$KDEDIR=$PREFIX.

*strucking horror* you mean ALL your system includes are there ?
mmh... ok... fine... why not... you are free to do it that
way indeed...
even if it sucks badly, not to offend ;)

Then again your last chance to build is probably
- && $filename =~ /\.h$/ ); # Not a backup file
etc. Only headers.
+ && $filename =~ /^q.*\.h$/ ); # Not a backup
file etc. Only headers.

in /smoke/qt/generate.pl.in, then run configure again....

With a bit of luck you won't have any other q* header in
your giant include dir...
I'll see later if I can come up with a complete list of
headers, but I hate it...
Is it really the standard way of installing
Qt/KDE/Everything on Darwin ?

G.

[germain garand]

Logged In: YES
user_id=145773

If it might help you to build in the mean time, my own
system reports I have no other q*.h in /usr/include, and
only one in /opt/kde3/include which is qxembed.h... so you'd
need to add this name in the @exclude array in the same file...
Just add a line like
'qxembed.h' => 1,

[Benjamin Reed]

Logged In: YES
user_id=375

Oh, no no no, I don't mean we stuff everything in the system
directory on MacOSX... =)

That would be just evil.

I package KDE/etc. for Fink, a "distribution" of open-source
stuff that sits on top of MacOSX. It's only user
applications and such, and we have our own root, so $PREFIX
!= /usr...

I will be out of town for a few days but I will give the
excludes a shot when I get back.

[germain garand]

Logged In: YES
user_id=145773

Ah OK... you scared me ! :)

I've just commited the new way of doing it to CVS
(use a closed list of all Qt headers)

Check it out and tell me ;)

G.

[Benjamin Reed]

Logged In: YES
user_id=375

I had a chance to give it a shot before leaving. Your
changes did it; thanks!

I've now run into an internal compiler error, but this
appears to be Apple's fault, so I'll have to get back to you...

x_QTSManip.cpp: In static member function `static void
x_QTSManip::x_0(Smoke::StackItem*)':
x_QTSManip.cpp:10: Internal compiler error in
simplify_gen_subreg, at
simplify-rtx.c:2715
Please submit a full bug report,
with preprocessed source if appropriate.

Whee!

[germain garand]

Logged In: YES
user_id=145773

>I had a chance to give it a shot before leaving. Your
>changes did it; thanks!

good, I'll close this one then

> I've now run into an internal compiler error

damn... hate them :-/
Any chance it could work by just adding extra spaces in the
relevant line ?
Anyway, if you find a simple workaround in the syntax, tell me.
And about the fixes to /Admin : are they mergeable with the
tree or do you always apply those manually to all KDE
buildsystems ?

G.

[Benjamin Reed]

Logged In: YES
user_id=375

I just got back into town, so I haven't had a chance to play
with making it happy by messing with the syntax.

As to the admin/ changes, I have a bunch of fixes that need
to go upstream, but they are currently maintained separately
in a KDE-Darwin tree at opendarwin.org. The big thing that
can't go upstream yet is libtool fixes, since the KDE guys
won't take admin/ changes to libtool until they've gone
upstream to the libtool guys first (so as to avoid the mess
that admin/ was before 3.0 when it got cleaned up and
libtool-1.4-ized).

As soon as I have the time to get things cleaned up for
presentation to the GNU folks, I'm going to merge a lot of
our stuff into mainline. Until then, we're gonna maintain
our own tree for a bit.