[cp-patches] Re: Make qt-peers build and run out of the box

[Dalibor Topic]

Mark Wielaard wrote:
> Hi,
>
> On Tue, 2005-08-23 at 21:07 +0200, Dalibor Topic wrote:
>
> > > The qt-peer/Makefile.am was also updated to not need any hacking of the
> > > include paths (this didn't work reliably if the path included multiple
> > > include directories, like with the default Debian install)
> >
> > Could you elaborate on that one?
>
>
> It replaces strings like /usr/include/qt with /usr/include/Qt/qt which
> is just plain wrong.

You are of course right, that is a simple bug in my sed scriptlet, and 
shouldn't take long to fix. I see that you have just posted another fix, 
which is cool, too. But as invested some time in making fun of the 
bikeshed discussion we're having here (and boy, are you soo wrong about 
the colour of it all!), I'll give you the funny ranting bits:

You may have missed the part in my original mail where I went to  great 
length to explicitely make sure that people mucking around with the Qt 
peers should *build their own* Qt4 library, and in particular not use 
the one in Debian unstable. I guess I was not loud and clear enough ;)

Let me repeat that: build your own Qt 4.0.1 library if you want to play 
with the qt peers in GNU Classpath. Don't use whatever your distribution 
provides, it is simply not good enough: you need the absolute bleeding edge.

In particular since, according to 
http://packages.qa.debian.org/q/qt4-x11.html the current version of Qt 4 
in debian unstable is Qt 4.0.0, which, as you said yourself, is not 
suitable for the Qt peers.

So, I have no idea how you managed to verify that your fix indeed works 
with Debian's Qt 4.0.1 release that does not exist yet according to 
debian buildds or the mailing list archive of debian-qt-kde list [1]. ;)

> > So ... I'll look into it, and see what I can do.
>
>
> Sure. For now I would like to have a working build though.

That's easy enough, and has been proven to work for several people, 
including yourself: build your own qt 4.0.1 installation and use that. ;)

> So if Sven can work with this I would like to commit this so everybody
> can start helping out and debug the new peers. OK?

Given that no suitable qt4 release exists in debian yet, I'd like to 
wait to see what the real qt 4.0.1 looks like in Debian proper, and till 
then a) fix the sed script to not be so easily thrown off track and b) 
try to see if we can get somewhere with qmake. You seem to have made 
some progress on a) in another patch, I'll give that a try on my system, 
too.

You obviously have a working setup yourself, judging by the screenshots 
you posted on your blog, so there is no need to make the source code of 
the peers worse[2] before it is clear that they are really necessary for 
Debian.

cheers,
dalibor topic

[1] http://lists.debian.org/debian-qt-kde/2005/08/index.html ... latest 
is qt4-x11-4.0.0-3.

[2] Well, debian sticks the includes in one place, someone else will 
surely stick them somewhere else, and I don't want to see the next patch 
"fixing" the includes by prepending a "include/qt3" path to all #include 
statements, just because some distribution decided that's the one true 
way to package the Qt4 includes or someone at Trolltech screwed up the 
pc files badly and made them return "-I/usr" for CFLAGS. ;)

Let me repeat this again: no distribution I know of currently ships a 
version of Qt4 that is suitable for GNU Classpath development, and 
probably will not do so for the rest of the year, because there is no 
need to do so. Build your own Qt 4.0.1 installation if your want to 
build the peers. Maybe I should post a patch for configure that prints 
that as a JIKES_STYLE_WARNING when people enable the Qt peers build. ;)