8 Commits

Author SHA1 Message Date
zhuk
2c19f63698 Add tests handling to devel/qmake, to be used by upcoming Qt 5.9, at least. 2017-06-15 15:55:14 +00:00
zhuk
890935dcd2 Make -recursive optional, it breaks quite a few upcoming Qt 5.9 ports.
Yes, this is a bug in qmake infrastructure, but Qt is moving towards qbs
anyway, so no reason to spend time on fixing qmake.
2017-06-15 08:54:46 +00:00
espie
3d9095e221 so qmake dependency handling is still basically broken.
mark everything that depends on it nojunk, because I'm fed up
of qt-creator and other things randomly breaking
2017-06-09 10:34:41 +00:00
zhuk
d049636848 Improvements for qmake.port.mk:
* Pass LIBfoo_VERSION environment variables like it's done for simple and
    gnu configure scripts. This unbreaks generating CMake config files
    in the upcoming Qt 5.6.2.

  * Don't call -recursive for Qt3's qmake, it doesn't support this flag.
2016-12-25 13:37:27 +00:00
sthen
6b9b7760bb fix systrace straggler, found by aja 2016-04-28 08:27:25 +00:00
zhuk
349cbe683e Define variables even when CONFIGURE_STYLE isn't set to "qmake",
making qmake.port.mk more declarative.
2016-03-26 21:03:03 +00:00
zhuk
ed298848a3 Zap more lines from qmake-based ports by moving them from
the "MODULES=x11/qtX + CONFIGURE_STYLE=qmake" logic to
the "MODULES=devel/qmake x11/qtX" logic.

Discussed with espie@ a few weeks ago.
2016-03-26 20:37:34 +00:00
zhuk
3b286ff983 Switch to a separate qmake.port.mk. Simplifies logic a lot.
This removes support of separate qmake versions in one port: as we
discovered, there are no ports actually needing this; strangers like
print/poppler don't use qmake in build.

This should be transparent to current ports. But expect more tweaks there:
for now, qt?.port.mk forces qmake.port.mk inclusion, but that will be
reworked to a more common scheme.

Same idea from (at least) espie@ and me; also, espie@ agrees on the plan.
2016-03-10 17:45:11 +00:00