On Sat, 25 Mar 2000 mcmahill@mtl.mit.edu wrote:

> 
> 
> 
> 
> On Sun, 26 Mar 2000, Berndt Josef Wulf wrote:
> 
> > mcmahill@mtl.mit.edu wrote
> > > 
> > > > I can't see an easy way of fixing this.
> > > > 
> > > > In hinsight, wouldn't it be easier to call the new qt-2.x stuff
> > > > libqt2 and moc2 and left libqt stuff alone? 
> > > 
> > > well, the problem is I assume that moving forward that qt-2.x will be the
> > > "standard" and qt-1.x will be obsolete.  KDE2 which is supposed to come
> > > out in a couple of months is supposed to have moved to qt-2.x.
> > 
> > What naming convention do you use on the qt-2 stuff  - libqt2 and
> > moc2? If so than libqt1 and libqt2 can co-exist by use of softlinks.
> > The problem then are the header files, but since there are
> > only a few apps using qt-2 right now (well when compared with all the
> > KDE stuff) wouldn't it be easier to supply the --with-qt-includes
> > argument for those at compile time? 
> 
> I haven't gotten to updating the qt pkg to 2.0.2 yet, but it appears that
> the default names are moc,libqt, and include/qt/.  Thats really what
> started this headache.  Qt-2 isn't backwards compatible with Qt-1 and it
> naming clashes making coexistence rough at best....


well, its ugly, but it looks like at least some of the configure scripts
would accept
  --with-qt-dir=${PREFIX}/qt1
or
  --with-qt-dir=${PREFIX}/qt2

then it looks in ${PREFIX}/qt1/{bin,lib,include} or 
 ${PREFIX}/qt2/{bin,lib,include} repspectively.  

Its ugly in that in violates hier(7), but nice in that its relatively easy
to control which Qt a pkg picks up, well at least for the autoconf'ed ones
which seems to include KDE.

comments?

-Dan