[kde-freebsd] qt upgrade strangeness

[Kris Kennaway]

On Tue, Apr 17, 2007 at 09:22:58PM +0200, Dejan Lesjak wrote:
> On Tuesday 17 April 2007 20:58:42 Michael Nottebrock wrote:
> > On Tuesday, 17. April 2007, Dejan Lesjak wrote:
> > > On Tuesday 17 of April 2007, Michael Nottebrock wrote:
> > > > On Tuesday, 17. April 2007, Michael Nottebrock wrote:
> > > > > On Monday, 16. April 2007, Andy Fawcett wrote:
> > > > > > Hi,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: John Nielsen [mailto:lists at jnielsen.net]
> > > > > > > Sent: Thursday, April 05, 2007 19:32
> > > > > > > To: kde at freebsd.org
> > > > > > > Cc: x11 at freebsd.org
> > > > > > > Subject: Re: [kde-freebsd] qt upgrade strangeness
> > > > > > >
> > > > > > > On Thursday 05 April 2007 12:29:27 pm John Nielsen wrote:
> > > > > > > > I've had some trouble upgrading qt on two different machines
> > > > > > > > now. I'm
> > > > > > >
> > > > > > > using
> > > > > > >
> > > > > > > > the experimental Xorg git ports tree on both and I'm not sure
> > > > > > > > if that's
> > > > > > >
> > > > > > > a
> > > > > > >
> > > > > > > > factor, which is why I'm CC-ing x11 at .
> > > > > > > >
> > > > > > > > In short, qt will install happily the first time but not the
> > > > > > > > second. It looks to my untrained eye like building [an
> > > > > > > > upgraded] qt when qt is
> > > > > > >
> > > > > > > already
> > > > > > >
> > > > > > > > installed somehow taints the build. The build will complete
> > > > > > >
> > > > > > > successfully,
> > > > > > >
> > > > > > > > but it will fail during the install step whether or not the old
> > > > > > > > qt was uninstalled between the make and install steps--I tried
> > > > > > > > an install
> > > > > > >
> > > > > > > without
> > > > > > >
> > > > > > > > uninstalling the old one using FORCE_PKG_REGISTER and it failed
> > > > > > > > differently, but it still failed. However, if qt and qmake are
> > > > > > > > removed completely before starting the [new] build for qt, it
> > > > > > > > will install just fine.
> > > > > > > >
> > > > > > > > I'd like to determine if 1) this is a known problem and 2) this
> > > > > > > > is
> > > > > > >
> > > > > > > specific
> > > > > > >
> > > > > > > > to the Xorg ports tree so I know whether or not to send in a
> > > > > > > > PR.
> > > > > > >
> > > > > > > I forgot to mention this was during an attempt to update qt from
> > > > > > > qt-copy- 3.3.8
> > > > > > > to qt-copy-3.3.8_1 on a 7-CURRENT (as of several days ago) box. I
> > > > > > > also saw the problem on a previous qt upgrade on a machine
> > > > > > > running 6-STABLE several weeks ago.
> > > > > >
> > > > > > Originally I reported that I wasn't seeing this.
> > > > > >
> > > > > > Now, I've just updated to the very latest git X11 ports, with
> > > > > > X11BASE migrated to LOCALBASE, and get this problem.
> > > > > >
> > > > > > cd src/moc && make
> > > > > > cd src/moc && make install
> > > > > > cp -f "../../bin/moc" "/usr/local/bin/moc"
> > > > > > cd src && make
> > > > > > make: don't know how to make /usr/local/include/qconfig.h. Stop
> > > > > > *** Error code 2
> > > > > >
> > > > > >
> > > > > > Quite weird, I've never seen this before.
> > > > >
> > > > > I dimly remember seeing that before - I don't think Qt/qmake can
> > > > > actually handle a PREFIX-move cleanly and once the prefix has
> > > > > changed, it has to be deinstalled *before* rebuilding it, or else
> > > > > this will happen.
> > > >
> > > > Since I understand there will be an update script for the upcoming
> > > > X.org upheaval, this issue would be a prime candidate for handling it
> > > > in such a script. flz, lesi, what do you think?
> > >
> > > Would bumping revision of qmake and qt be enough or were you thinking of
> > > something more aggressive?
> >
> > No - I'm guessing the problem is that qmake generates wrong dependencies in
> > Makefiles when it configures Qt with a prefix that is different from the
> > one of a previously installed Qt, with the dependencies being generated on
> > files in the destination install prefix instead of the workdir. The most
> > obvious workaround: Deinstall (as in make deinstall) qt33, then (and only
> > then) rebuild and reinstall qt33 with the new PREFIX set. An update script
> > could take care of this rather easily as part of a post-update cleanup
> > routine.
> >
> > I can also try to reproduce this and, if I succeed, try to come up with
> > some post-configure in-place Makefile editing, if my guess turns out to be
> > correct, but I am still busy with changing a number of qt4 ports to avoid
> > conflicting with qt33 after the X11BASE-move and flz@ already told me would
> > very much like to remain on schedule and do the merge on the upcoming
> > monday - I'm simply not sure I will be able to address this problem in
> > time.
> 
> Errrrm...  does this failure happen with /usr/X11R6 -> /usr/local symlink in 
> place or without it?

Without, presumably - that symlink can only be added after the
upgrade, once everything has been rebuilt, so it won't help with
failures trying to perform that rebuild.

Kris