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.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Dec 28 2021
Jan 10 2020
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.
Jan 5 2020
Nov 28 2019
Sep 26 2019
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
Aug 5 2019
Jun 8 2019
Jan 8 2019
Sorry, was busy with other stuff so completely forgot about this. I'll update this soon.
Oct 23 2018
Makes sense, I didn't think about multiple languages being set when I wrote that code.
Sep 19 2018
Looks good to me.
Sep 14 2018
I haven't tried the QtSDK parts yet, but the blacklist seems to work.
Sep 13 2018
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
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.
Sep 12 2018
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?
Sep 11 2018
Sep 10 2018
Fix typo in comment
Sep 9 2018
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.
Sep 5 2018
Committed to master as commits R138:862353272ad0653e18c745a27c65e39719a635e0 to R138:0d768777eef749c562ee294227ef9d1b3f93bd1c
Sep 4 2018
Sep 3 2018
In D15235#319464, @vonreth wrote:did you by accident invert the before and after value?
Aug 28 2018
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...