classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dalibor Topic
Subject: [cp-patches] Re: Make qt-peers build and run out of the box
Date: Wed, 24 Aug 2005 03:17:38 +0200
User-agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)

Mark Wielaard wrote:
Hi Dalibor,

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

The old configure stuff did not replace any files. It merely added a sed-munged cpp flag to the original broken cpp flag ;)

But, semantic joking aside, your latest patch is clearly a big improvement over both the previous patch and the original code. Thanks for writing it and taking the time to improve it, you've done some really nice work there. And you got rid of the sed bit, which is always a plus. ;)

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.

Yeah, I understand your excitement, I am excited about them too ;)

Let me nevertheless bring the excitement level down a bit:

The build will not work out of the box for normal people for at least another 3-6 months, until distributions actually start shipping the respective necessary qt4 release. The current target group for the peers is afaict the regulars on #kaffe, #classpath and #gcj, as long as FC 5/6, and the next Debian & Ubuntu releases carrying KDE 4 are out. I would not expect too much external uptake at this point of time, really.

If you are looking for external testing & patches, you may want to talk with bero & KDE developers like zander to see if someone in that camp is interested. Placing an article on the dot would be useful, eventually, for example.

If you have a better build system please post a patch.

Right now, nope. I think it's as good as it gets wrt to using automake atm, thanks to your good work.

I'll investigate using qmake, as well, as it would allow us to get rid of the pkg-config broken-flags business for good.

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.

Yeah, they are a very good idea. good work!

cheers,
dalibor topic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]