Well the code is header only, so gcc can use it too.
Everything needed is to pull in a binary, that's not ideal but I guess its better than no notifications on Windows.

Sounds ok
Craft is now on invent.kde.org so you can use pull requests.

Lets hope for the best

besides the qml install path this looks much more sane.

As it looks like the install script sucks... and I expect it to just copy the binaries and some headers...
Can we just do it with our functions?

Well if the patch works...
Else pls motivate the maintainers if mingw to provide a new binary release.

Hm maybe put it into an if msvc?

I’d the fortran part used at all? Can we just disable it?

Hm maybe put it into an if msvc?

And you setting the mingw Version there won't work. That is only assuring that at least that version is installed. >=.

Because mingw builds stopped providing builds.
I won't donwngrade mingw for some weird package.
Can we disable the fortran part?

In D28536#640890, @maxrd2 wrote:

In D28536#640738, @vonreth wrote:

Hm yes sounds like we should fix our ffmpeg blueprint with a post install step.

Created patch here: https://phabricator.kde.org/D28543

In D28536#640739, @vonreth wrote:

And for the include path, could we patch the qmake project file.

Sure, but how do I place craftRoot into a .qmake file?
BTW those steps I've added to .qmake.conf file are what I've read on official build steps here: https://github.com/wang-bin/QtAV/wiki/Build-QtAV#recommended-edit-qmakeconf-if-use-qmake

And for the include path, could we patch the qmake project file.

Hm yes sounds like we should fix our ffmpeg blueprint with a post install step.

Is the dynamic lib also in the lib64 folder?
If so we should find out how to disable that....

Well I have to trust you with the tarballs