RFE: add a qmake portgroup

[cooljeanius (Eric Gallager)]

qmake currently has multiple issues that ports have to work around (as brought up in tickets #38272 and #38250):

• qmake isn't UsingTheRightCompiler (cf. comment:ticket:38250:1)
• qmake doesn't handle -arch flags properly (cf. comment:ticket:38250:2)
• qmake doesn't handle the --disable-dependency-tracking flag properly (cf. comment:ticket:38272:1)

And I'm sure there's other things that could be done with a qmake portgroup, too.

[cooljeanius (Eric Gallager)]

oops this wasn't supposed to be a "defect"

[mf2k (Frank Schima)]

Cc Me!

[cooljeanius (Eric Gallager)]

initial attempt at creating a qmake portgroup

[cooljeanius (Eric Gallager)]

Attached my first try at this, not exactly sure how to go about testing it...

[michaelld (Michael Dickens)]

Good start. I think we'll also want to try to overwrite the options for +universal and +debug, as well as add flags for OBJC and OBJCXX.

To test the file, make sure it is in "dports/_resources/port1.0/group/", then you'll need to modify some Portfile which requires QMake to make use of it, via adding "PortGroup qmake 1.0" somewhere before you need the settings / variables.

[cooljeanius (Eric Gallager)]

Replying to michaelld@…:

Good start. I think we'll also want to try to overwrite the options for +universal and +debug

What do you mean by "overwrite" here? Just put in blank variants, or are there any specific settings we should be using for these variants?

[michaelld (Michael Dickens)]

"overwrite" means in this case to set the QMake-specific variable on the ${configure.cmd} line, and hope that they overwrite those from the project's build script. When we set "QMAKE_CC=${configure.cc}", it generally works because projects are not supposed to play with it. But, setting for +debug and +universal is more generic, and hence takes a bit of work: (1) setting the ${configure.cmd} line correctly; and (2) making sure those variables are not set in the project's qmake build scripts.

For example, +debug for MacPorts generally means to install but release and debug versions, and hence IIRC does something like:

if +debug {
  CONFIG += debug_and_release build_all
} else {
  CONFIG += release
}

+universal I think can use:

if +universal then {
  CONFIG += ${qt_arch_types}
}

All of the above need to be on the configure.cmd arguments line, so in quotes appropriately. Then, inside the project we would need to remove references to these variables so that the overwrite is guaranteed to work.

[cooljeanius (Eric Gallager)]

idk, I'm still kind unclear about all this, so I'll just attach my latest version of the portgroup, and then let you guys make changes as you see fit. (I tested it with qdjango and it works properly with that port at least, btw)

[cooljeanius (Eric Gallager)]

my latest attempt at the qmake portgroup

[NicosPavlov]

Cc Me!

[NicosPavlov]

It seems a hassle to have to modify the project in order to change the references to some variables individually. I made some tests with qmake, and it seems that adding

variant debug description "Enable debug binaries" {
    configure.pre_args-append   "CONFIG+=debug"	
}

does the trick to enable debug, as "debug" has precedence over "release" when both are invoked. Additionally, it seemed that "debug_and_release" can lead to some issues when building.

Similarly, adding

if {[variant_isset universal]} {
    pre-configure {
        configure.pre_args-append   "CONFIG+=\"${qt_arch_types}\""
    }
}

seem to work for universal build.

[NicosPavlov]

Should the portgroup be committed ? As there have been no additional comments or suggestions for several weeks, would it be safe to assume that it seems satisfactory ?

[michaelld (Michael Dickens)]

I will have time this coming week to deal with this ticket; just been too busy the last few weeks.

[michaelld (Michael Dickens)]

Sorry for the delay; it's just been crazy since my last posting here, with required time away to handle multiple personal matters. I should be able to get to this issue this week.

[michaelld (Michael Dickens)]

OK; obviously I haven't had time for this, so I'd say for someone else to go ahead and check this in and start using it. I don't know when I will find time for this in the coming weeks.

[cooljeanius (Eric Gallager)]

Replying to michaelld@…:

OK; obviously I haven't had time for this, so I'd say for someone else to go ahead and check this in and start using it.

I would if I could... (my application for commit access is still pending review...)

[NicosPavlov]

I should be able to finalize the tests and commmit it in the next days.

Unless there are objections, I will make final checks based on the last modifications I proposed, giving the attached file.

[cooljeanius (Eric Gallager)]

Replying to nicos@…:

I should be able to finalize the tests and commmit it in the next days.

Unless there are objections, I will make final checks based on the last modifications I proposed, giving the attached file.

Looks good to me, feel free to go ahead and commit it.

[NicosPavlov]

Committed in r106912.

I made a small change after testing it, in order to ensure that instructions in the Portfile (such as compiler.blacklist) would be taken into account when setting variables in the portgroup.

[cooljeanius (Eric Gallager)]

Yay! Now to actually use it in all the ports it's appropriate for...

[mf2k (Frank Schima)]

@nicos: Thank you!

@egall: Feel free to open up a single ticket with all such ports. It would be good to know.

[cooljeanius (Eric Gallager)]

Replying to macsforever2000@…:

@egall: Feel free to open up a single ticket with all such ports. It would be good to know.

OK, #39424