In hindsight I feel like I should not have "designed" the KPluginMetaData API this way. I don't really like constructors that can fail and leave the object in an invalid state. But changing that now doesn't make any sense.

I may be misunderstanding this, but if Qt builds against a 10.13 target and we build frameworks against 10.12, is there any chance of breakage?
I can't think of any immediate problems since it should just mean Qt can use new APIs and no longer uses old deprecated ones.

I originally tried to make the qt5 version installed by homebrew usable for KDE frameworks (e.g. find syntax files etc.) Currently you have to manually create symlinks in $HOME to /use/local/ to allow applications to find stuff. See https://github.com/KDE-mac/homebrew-kde/blob/master/tools/do-caveats.sh

Sorry, was busy with other stuff so completely forgot about this. I'll update this soon.

Makes sense, I didn't think about multiple languages being set when I wrote that code.

Looks good to me.

LGTM

I haven't tried the QtSDK parts yet, but the blacklist seems to work.

I can confirm that this fixes the build for me.

Fix name

Pick a name that shows that it is a boolean

Add missing newline

Build using autotools on non-Windows systems since that is the supported way.

fix

Better approach

Ah yes of course I didn't think about that. How about self.subinfo.options.configure.defaultAutoreconfIncludes = False? So far the only thing that was necessary is to not add the default include path.

I have needed this for 3 packages now (libunistring, libtasn1 and aqbanking). Do we really need to override the project aclocal files with the ones from the craftroot? According to the mailing list message prefix/share/aclocal will be searched automatically.

I guess the other option is to just use the autotools build for linux/mac?

I found https://github.com/acmepjz/djvulibre with cmake build system, should we be using that instead?

Fix typo in comment

According to http://doc.qt.io/qt-5/supported-platforms.html the minimum version is 10.11 so this should be fine.
As long as we update this version whenever Qt doesn't build keeping it in sync shouldn't be too difficult.
I also don't think it would be a problem if the minimum supported macos version for other software is lower than the Qt minimum.

Committed to master as commits R138:862353272ad0653e18c745a27c65e39719a635e0 to R138:0d768777eef749c562ee294227ef9d1b3f93bd1c

In D15235#319464, @vonreth wrote:

did you by accident invert the before and after value?

Ping?

In D15116#316574, @vonreth wrote:

Hardcoding would again make testing harder, but we might just add a patch to use the relative path to qappDir/…./share as a fallback, or maybe we can even detect whether we are in a bundle or in a build root?

It should be easy to detect whether we are in a bundle or not. I can also check if the current executable is below qtpaths --install-prefix and if so add $(qtpaths --install-prefix)/share.

In D15116#316553, @vonreth wrote:

In D15116#316544, @arichardson wrote:

In D15116#316539, @kfunk wrote:

In D15116#316522, @vonreth wrote:

ok then the main question is, do we need to deploy extra libs? they should already be in the image, and removing this functionality would simplify the code?

Initially I've used MacDylibBundler to pull in libs from packages installed via Brew. Nowadays we built (almost?) everything ourselves using Craft, right? There might still be some libs which need to be pulled into the .app, though, if it's not tracked by Craft... But I honestly do not know the current state of affairs re. Craft on macOS...

I noticed it pulled in at least libgit2.dylib and editorconfig.dylib from homebrew.

The one thing that is missing for any application to work on MacOS is the ability to override QStandardPaths::GenericDataLocation. The app bundle seems to work because it bundles all of share/ into Contents/Resources but if I try to run the kate.app created by craft in ~/kde/Applications it doesn't find anything.
I can (almost) get it to work by removing kate.app/Contents/Resources and turning that into a symlink to ~/kde/share. If I do that kate works fine when launched from the console ./Applications/KDE/kate.app/Contents/MacOS/kate foo.txt but if I double click on the .app or use open -a all icons are missing and lots of stuff is broken.

Hm are you using our qt build, we apply https://github.com/KDE/craft-blueprints-kde/commit/f7513dc802ee29db1c61dc6e3f9f4e729b418a4a

In D15116#316539, @kfunk wrote:

In D15116#316522, @vonreth wrote:

ok then the main question is, do we need to deploy extra libs? they should already be in the image, and removing this functionality would simplify the code?

Initially I've used MacDylibBundler to pull in libs from packages installed via Brew. Nowadays we built (almost?) everything ourselves using Craft, right? There might still be some libs which need to be pulled into the .app, though, if it's not tracked by Craft... But I honestly do not know the current state of affairs re. Craft on macOS...