Upgrade Qt Mobility to Git version and fix build on case sensitive filesystems

[thp]

Fixes:

invalid conversion from ‘void (* const)(QObject*, QMetaObject::Call,
int, void**)’ to ‘int (*)(QMetaObject::Call, int, void**)’

Also fixes (via a patch) a build error on case sensitive filesystems.

Replaces #10176

[thp]

By the way, I do get warnings, not sure if I should "rm -rf "*.app" there after the installation:

Warning: Non-executables were installed to "bin".
Installing non-executables to "bin" is bad practice.
The offending files are:
/usr/local/Cellar/qt-mobility/1.2.0+git/bin/icheck.app
/usr/local/Cellar/qt-mobility/1.2.0+git/bin/qcrmlgen.app
/usr/local/Cellar/qt-mobility/1.2.0+git/bin/servicedbgen.app
/usr/local/Cellar/qt-mobility/1.2.0+git/bin/servicefw.app
/usr/local/Cellar/qt-mobility/1.2.0+git/bin/servicexmlgen.app
/usr/local/Cellar/qt-mobility/1.2.0+git/bin/vsexplorer.app

How would I include this in the formula?

[MikeMcQuaid]

Look at the Qt formula and move the .app files out of bin and into the prefix.

[thp]

I'm pretty sure we want to make the Git master the stable one, as the current 1.2.0 release does not build in Homebrew on Mac OS X, even with the patch applied. There probably won't be a new Qt Mobility release (all resources are put into merging Qt Mobility stuff into Qt 5, as somebody has written in the bug report that I linked in my original issue).

So, why not just make the "master" branch (which does build and work) the stable one? Upstream will definitely not release a new version from Git just because we tell them to :/ Otherwise, another option would be to just leave 1.2.0 broken there and ask users to use "--HEAD" for Qt Mobility, but that's not really the point of it, or is it? :/

[mistydemeo]

@thp We still prefer not to have HEAD-only formuale, given the potential for new commits to change things unexpectedly. It makes support much harder if, say, a commit breaks builds sometime down the line.

If there is no appropriate stable version or tag, and the patches to apply to 1.2.0 to make building work are too large or impractical, then you should pick a known-stable revision from the git tree and use that as the stable version. You can use that in the url field by doing

url 'git://gitorious.org/qt-mobility/qt-mobility.git', :revision => 'foo'
version '1.2.0-foo'

[thp]

mistydemeo: Thanks. I just found out that a stray /usr/bin/qmake from a Qt SDK install was giving me problems with the 1.2.0 build, so I'll try to build again and see if I can avoid the error in the formula. If this works, then maybe 1.2.0 does build after all, if not I'll take the current head and fix the revision as you suggested - thanks!

[thp]

Pull request updated. This should now move the .app directories out of the way (like the Qt formula) and build properly, even when Qt SDK has installed /usr/bin/qmake. Please test and review.

From my point of view, this is ready to be merged, but I'm happy to rework stuff that's still problematic.

[jacknagel]

Check the indentation here

[thp]

Integrated suggestions from jacknagel - please review again. The "prefix.install Dir["{#bin}/*.app"]" didn't work, so I left it the same as the "qt" formula.

[mistydemeo]

Now that you've determined that the stray qmake was causing a problem, is it still necessary to use a git revision, or will 1.2.0 work?

[thp]

Yes, it's still necessary to use the Git revision.

[adamv]

Willing to pull this to clear it out; either have to pull or redact the formula (which seems heavy-handed.)

[thp]

Yes, please pull it - it has been quite some time since this was reported and fixed via a pull request and (as you can see in the comments here) has been cleaned up and should be ready to go in now. Why waste all that work and remove the formula?

[tilladam]

I have submitted a patch fixing this upstream and it was merged today into master as: Ie34e1b4ca7e232920adc6eebf4754db0b52eab98

It should be ok to change this formula to use master again.

[MikeMcQuaid]

@tilladam Hello :) We try to keep Homebrew pegged at certain revisions rather than just follow master. Do you think we should update to point to your patch's revision now? What are the chances of coaxing a 1.2.1 release/tag out with this stuff in it?

[tilladam]

On Sunday 20 January 2013 14:12:50 Mike McQuaid wrote:

@tilladam Hello :) We try to keep Homebrew pegged at certain revisions rather
than just follow master. Do you think we should update to point to your
patch's revision now? What are the chances of coaxing a 1.2.1 release/tag out
with this stuff in it?
—
Reply to this email directly or view it on GitHub.

I've created a merge request now, based on the merged commit. Thomas is
working on getting a tag out, yes. Depends on some upstream (Qt) decisions,
though.

Till

Till Adam - Managing Director Germany, Services Director
KDAB (Deutschland) GmbH & Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions