Ports that use qmake: consider using the new qmake portgroup

[cooljeanius (Eric Gallager)]

(Made as a separate ticket per comment:ticket:38280:22) There is now a qmake portgroup as of r106912. Here is a list of ports that use qmake somewhere in their respective portfiles:

[moved to attachment:qmake_search.txt​ because it’s pointless and makes ticket modification emails enormous. —larryv]

That list, with just the ports, and the irrelevant ones removed, becomes:

• abtransfers [r106975, see comment:4 and r107026, see comment:12]
• arora
• bitcoin [r108515, see comment:18]
• bitdht [no benefit, see comment:14]
• clustalx
• cmake [no benefit, see comment:14]
• djview [no benefit, see comment:10]
• doxygen [no benefit, see comment:14]
• GLC_lib
• gnuradio [no benefit, see comment:14]
• goldendict (note: nomaintainer)
• gwenhywfar4 [no benefit, see comment:5]
• k3dsurf (note: nomaintainer, purely based on qt3)
• kdiff3 (note: nomaintainer)
• libQGLViewer [r107011, see comment:11]
• mythtv-core.25 [no benefit, see comment:7]
• OpenCSG
• openscad
• psi-otr
• py-pyqt4 [no benefit, see comment:14]
• py26-pyqt3 [no benefit, see comment:14]
• qca [no benefit, see comment:14]
• qfsm [no benefit, see comment:14]
• qgit
• QMK-Groundstation
• qscintilla (note: nomaintainer)
• qt-assistant
• qt4-creator-mac
• qt4-mac-mysql55-plugin
• qt4-mac-postgresql91-plugin
• qt4-mac-sqlite2-plugin
• qtc-qtsharp (note: nomaintainer)
• qtiplot [r106995, see comment:10]
• qtpfsgui
• qtscriptgenerator
• qtsharp (note: nomaintainer)
• QupZilla
• qwt
• qwtplot3d
• qxmpp
• sqlitedbrowser
• tea
• texstudio (note: nomaintainer)
• tiled (note: nomaintainer)
• Vidalia [no benefit, see comment:14]
• x2goclient
• xxdiff [no benefit, see comment:14]

Maintainers of these ports, consider whether you could use the qmake portgroup for your respective ports.

[ctreleaven (Craig Treleaven)]

I've browsed the linked tickets, but I didn't notice a reason that this is a separate port group. Why not just add these bits to the qt4 port group (maybe version 2.0)?

Also, I noticed the line:

    configure.pre_args-delete       --prefix=${prefix}

I'm pretty sure mythtv-core.25 needs that argument. Is it harmful to other ports?

[cooljeanius (Eric Gallager)]

Replying to ctreleaven@…:

I've browsed the linked tickets, but I didn't notice a reason that this is a separate port group. Why not just add these bits to the qt4 port group (maybe version 2.0)?

I wanted to just include this in the qt4 portgroup, too, but apparently not all ports that use the qt4 portgroup use qmake, so that's why there's now a separate qmake portgroup. See comment:ticket:38272:1 for reference.

[NicosPavlov]

The portgroup is not meant for all ports using qmake. For example, several ports use qmake within standard autotools, thus compiling by

configure
make

These ports are not concerned by this portgroup, as they define variables during the configuration phase. However, several other ports must be compiled through

qmake
make

The portgroup aims at setting variables for these ports.

Typically, in case the configuration phase is made with qmake, the --prefix argument is not used, and PREFIX is, hence the changes of variables in the portgroup. Due to these differences, it did not appear suitable to include these in the qt4 portgroup which is more general for ports depending on qt4.

[mkae (Marko Käning)]

Done for abtransfers in r106975

[mkae (Marko Käning)]

I think gwenhywfar4 should be taken out of the above list, since it uses configure!

[cooljeanius (Eric Gallager)]

Replying to mk@…:

I think gwenhywfar4 should be taken out of the above list, since it uses configure!

I'd edit it to do so, except people without commit access can't edit the OP's of tickets (even if they're their own tickets), so I can't (yet)...

[ctreleaven (Craig Treleaven)]

mythtv-core.25 also uses ./configure and would not benefit from this portgroup.

(And yes, tickets can be assigned to us...but we can't close them or do anything more than comment on them!)

[larryv (Lawrence Velázquez)]

Removed gwenhywfar4 and mythtv-core.25.

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Here is a list of ports that use qmake somewhere in their respective portfiles:

By the way, please use better judgment in the future when pasting a ton of output from logs or stdout into ticket descriptions or comments. Where by “use better judgment” I mean “don’t do it”.

[NicosPavlov]

qtiplot done in r106995.
Suppressing djview as it uses configure.

[raphael-st (Raphael Straub)]

libQGLViewer done in r107011.

[mkae (Marko Käning)]

modified abtransfers' Portfile in r107026

[larryv (Lawrence Velázquez)]

original search output, removed from ticket description

[NicosPavlov]

I passed through the listed ports, and tried to clean up the irrelevant ones, i.e. the ones for which the quake portgroup would be of no use.

• Ports using standard autotools (eg ./configure): bitdht, cmake, doxygen, qca, qfsm, Vidalia
• Ports using cmake: gnuradio
• Ports using python: py-pyqt4, py26-pyqt3
• Ports without configure phase: xxdiff

Additionally, I noted that some ports employ some conditional code to take into account the case of qt3, which is not considered in the portgroup for now.

I also made a note beside ports which have no maintainer.

[neverpanic (Clemens Lang)]

What's the rationale behind setting configure.* in a pre-configure block in the PortGroup? This makes it difficult to change the defaults given in the PortGroup.

[cooljeanius (Eric Gallager)]

Replying to cal@…:

What's the rationale behind setting configure.* in a pre-configure block in the PortGroup? This makes it difficult to change the defaults given in the PortGroup.

I think nicos did that in comment:ticket:38280:20...

[NicosPavlov]

Sorry I did not answer right away.

If I did put those in a pre-configure block, it is because otherwise, the flags were not set right if the portfile was for example setting configure.blacklist, as flags such as QMAKE_CC must be set accordingly, and after having blacklisted compilers. This is also why all flags are with -delete or -append. However, I fully get the point, and if there is another more convenient way of ensuring that some commands are followed that I am not aware of, it surely could improve the portgroup.

[easye]

Addressed for finance/bitcoin in r108515.