KDE/kdelibs/cmake/modules

[Alexander Neundorf]

On Tuesday 02 January 2007 20:50, Marc Espie wrote:
> On Tue, Jan 02, 2007 at 08:39:36PM +0100, Alexander Neundorf wrote:
> > On Sunday 31 December 2006 16:00, Marc Espie wrote:
> > > SVN commit 618204 by espie:
> > >
> > > find the right qmake on OpenBSD...
> > >
> > >
> > >  M  +1 -1      FindQt4.cmake
> > >
> > >
> > > --- trunk/KDE/kdelibs/cmake/modules/FindQt4.cmake #618203:618204
> > > @@ -172,7 +172,7 @@
> > >  ENDIF(WIN32)
> > >
> > >  # check for qmake
> > > -FIND_PROGRAM(QT_QMAKE_EXECUTABLE NAMES qmake qmake-qt4 PATHS
> > > +FIND_PROGRAM(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake qmake-qt4 PATHS
> >
> > This will break if you need qt-copy, because then still qmake4 will be
> > preferred over the qmake coming from qt-copy. I suggest moving qmake4
> > behind qmake. Then you have to make sure that no qmake is in the PATH.
>
> I have a qmake in the path, unfortunately, and it's not easy to move it
> out of the way.
>
> I would vote for getting qt-copy to create a qmake4... really sounds least
> confusing. I gather a lot of installations out there will have qmake
> aliased to qt3.

Having three names for the same tool sucks. And having one of these names 
additionally used for another slightly incompatible tool sucks even more.

If Trolltech would rename qmake to qmake4 starting with Qt 4.3 this would make 
things even more confusing.

Having qt-copy generating "qmake4" might be an idea. Or qt-copy-qmake4 ? This 
would ensure that this one is always (at least currently quite often) 
preferred over qmake.

Other comments ?

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net