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

[Mark Wielaard]

Hi Dalibor,

On Wed, 2005-08-24 at 01:31 +0200, Dalibor Topic wrote:
> > 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.

The idea of the patch is to actually test where the include files are
instead of blindly replacing them.

> 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.

The patch updates the version number we check against (4.0.1 or higher)
to make sure that the user has the right version.

> 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]. ;)

The packaged Qt 4.0 works fine if you disable the qtembedded support,
but I don't recommend that or want to provide a configure option for
that since I assume 4.0.1 will be officially available soon enough.

> 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.

I just want the build to work out of the box now so people can start
playing with the new stuff so we have some extra testing time before the
release. If you have a better build system please post a patch.

> [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. ;)

The autoconf tests I added should notice that situation and issue a
warning in that case. We cannot predict the future, but I think the
tests I propose cover the most likely installation/configuration
options.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part