John,
On Tue, Feb 24, 2004 at 02:11:02AM +0000, John Levon wrote:
> On Mon, Feb 23, 2004 at 07:45:15PM -0500, Zvezdan Petkovic wrote:
>
> > automagically defined. The trouble is that LyX's configure doesn't
> > respect MOC and UIC environment variables and overwrites them.
> >
> > The patch mentioned in the comment above that would fix this is
> > attached below.
>
> I can't say I like it. Why can't you just set up PATH correctly ? I'm a
> bit sick of every OS/distro doing Qt versioning in completely different
> ways. Trolltech don't care because they want you to use qmake.
I don't think you quite understood the details.
PATH is set up correctly and has nothing to do with this.
I didn't want to go to all the details in the first email, but it seems
I have to.
LyX configure script looks for moc2 and moc only.
On OpenBSD it happens to be moc3-mt. And it never gets found.
If a user on OpenBSD installs KDE, (s)he will get qt3-mt package
installed as a dependence, as well as qt3-base. If (s)he installs an
older KDE package or a package that doesn't work with thread, that
package will perhaps depend on the plane qt3 or even qt2.
The only way to have all of them in the same time is to call them
differently (moc2, moc3, moc3-qt) and store the libraries in different
places (/usr/local/lib/{qt3,qt2}).
Now, as a port builder you mostly do not worry about this. The OpenBSD
port infrastructure takes care of the gory details in a very simple way.
You just add to your port's Makefile this line:
MODULES+= qt
and if you're going to use threaded version
MODQT_MT= Yes
That is all. A side effect of that is that the important environment
variables for the build process get extra values.
CONFIGURE_ENV, MAKE_ENV, and MAKE_FLAGS all get these values added if
MODQT_MT=Yes (otherwise -mt suffix is not there):
MOC=${LOCALBASE}/bin/moc3-mt
UIC=${LOCALBASE}/bin/uic3-mt
MODQT_INCDIR=${LOCALBASE}/lib/qt3
MODQT_LIBDIR=${LOCALBASE}/include/X11/qt3
Besides, the variable LIB_DEPENDS, which determines port (package)
dependencies is added to appropriately (lib/qt3/qt-mt.3::x11/qt3,mt),
and the important variable is set:
MODQT_CONFIGURE_ARGS= --with-qt-includes=${MODQT_INCDIR} \
--with-qt-libraries=${MODQT_LIBDIR}
Notice that as a port builder you do _not_ worry about this. This is
all performed by a ports infrastructure on your behalf because of the
line MODULES+=qt.
So, what I did in the port is after MODULES+=qt and MODQT_MT=Yes lines:
CONFIGURE_ARGS= --with-frontend=qt ${MODQT_CONFIGURE_ARGS}
which adds the correct Qt include and library directory paths using
configure options --with-qt-{includes,libraries}.
Since CONFIGURE_ENV _already_ has MOC=${LOCALBASE}/bin/moc3-mt and
UIC=${LOCALBASE}/bin/uic3-mt I'd expect a configure script to respect
these environment variables. It doesn't. Because it looks for moc2 and
moc without even checking whether these variables are set.
That's why I had to trick them that ac_moc1 and ac_uic are already set
by passing this:
CONFIGURE_ENV+= ac_moc1=${MODQT_MOC} ac_uic=${MODQT_UIC}
However, it's sort of a hack, rather than a solution.
Respecting $MOC and $UIC would be a solution. That's what the qt.m4
patch was all about.
>
> > 2. Another problem with configure is that it tries to compile a simple
> > Qt application testing different variants of Qt libraries, but
> > doesn't link thread library with qt-mt. Since OpenBSD installs qt-mt
> > by default (for KDE) that was the version I had. Configure couldn't
> > pass because the libraries wouldn't link without -pthread.
> >
> > Fix was to pass LIBS=-pthread to configure
> > ----->8-----
> > CONFIGURE_ENV= LIBS=-pthread
> > ----->8-----
> > This line was used before the += line shown in the previous point.
> >
> > I don't know if this is platform specific or not. Keeping this line
> > in the port is not big deal if it's OpenBSD specific.
>
> This could easily go wrong ... I do not know what the correct/best thing
> is here.
As I said, having the above in the OpenBSD port Makefile only is fine
for me. I just wanted you to know, that if the library is -mt it
wouldn't link even the simple configure test program without the
appropriate thread library in the environment. You, as developers may
want to investigate this issue.
--
Zvezdan Petkovic <[EMAIL PROTECTED]>
http://www.cs.wm.edu/~zvezdan/
