Changes to MacOS build

[vkbo]

Summary:

This is a continuation of #1276 by @Ryex

Related Issue(s):

Reviewer's Checklist:

• The header of all files contain a reference to the repository license
• The overall test coverage is increased or remains the same as before
• All tests are passing
• All flake8 checks are passing and the style guide is followed
• Documentation (as docstrings) is complete and understandable
• Only files that have been actively changed are committed

[vkbo]

@Ryex

There are some issues with the app bundle. For one, it's 176 MB. A lot of that is because there is both a "python3.1" and "python3.10" folder in Resources/lib. That seems wrong to me. Any ideas?

Also, can you test the artifacts?

[vkbo]

Ok, tested the app bundle on my macOS VM, and it ran just fine. Couldn't get the DMG one to work though, just got a window with an icon that did nothing. Maybe I'm doing something wrong.

[vkbo]

I ran the conda command in an Ubuntu VM, and it does indeed create a "python3.1", but as a symlink to "python3.10" I guess the safest would be to preserve symlinks in the build too.

[Ryex]

I ran the conda command in an Ubuntu VM, and it does indeed create a "python3.1", but as a symlink to "python3.10" I guess the safest would be to preserve symlinks in the build too.

This is correct, I'm not sure why it's done this way but it's probably preferable to preserve it.

I'll test the dmg here shortly

[Ryex]

@Ryex

There are some issues with the app bundle. For one, it's 176 MB. A lot of that is because there is both a "python3.1" and "python3.10" folder in Resources/lib. That seems wrong to me. Any ideas?

Also, can you test the artifacts?

The size of the app bundle is sadly not something that can be worked around. the bundle contains all the libs (python, qt, enchant, etc) it needs to run with the assumption that it can not pull anything from the system. This is the design of app bundles and why they work (for the most part) universally across mac os versions.

[vkbo]

I ran the conda command in an Ubuntu VM, and it does indeed create a "python3.1", but as a symlink to "python3.10" I guess the safest would be to preserve symlinks in the build too.

This is correct, I'm not sure why it's done this way but it's probably preferable to preserve it.

It didn't work, so I've now tried to remove it. As far as I can figure out, it's a backwards compatibility thing for older conda versions. I bet they treated the Python version as a number, where 3.10 becomes 3.1. See: conda/conda#11423 (comment)

I'll test the dmg here shortly

Great. I noticed that it isn't always built properly though. Same error as mentioned here: create-dmg/create-dmg#74

[vkbo]

The size of the app bundle is sadly not something that can be worked around. the bundle contains all the libs (python, qt, enchant, etc) it needs to run with the assumption that it can not pull anything from the system. This is the design of app bundles and why they work (for the most part) universally across mac os versions.

Oh, it can definitely be worked around. I reduced the size of the windows package quite a lot by deleting components of Qt not needed by novelWriter. It actually only needs core, widgets and svg. I got it down to just over 100 MB, which is good enough for now.

[Ryex]

The size of the app bundle is sadly not something that can be worked around. the bundle contains all the libs (python, qt, enchant, etc) it needs to run with the assumption that it can not pull anything from the system. This is the design of app bundles and why they work (for the most part) universally across mac os versions.

Oh, it can definitely be worked around. I reduced the size of the windows package quite a lot by deleting components of Qt not needed by novelWriter. It actually only needs core, widgets and svg. I got it down to just over 100 MB, which is good enough for now.

True enough, there is a reason I was pruning the web-engine after all. so long as your aware of what your pruning and why it can be cut down a bit further.

[vkbo]

True enough, there is a reason I was pruning the web-engine after all. so long as your aware of what your pruning and why it can be cut down a bit further.

All of the QtQuick/QML stuff can be pruned too, so can the database and other bits. But it's a lot of stuff to loop through and remove. I do it here for Windows:

novelWriter/setup.py

Lines 1291 to 1324 in 8273fcc

	delQt5 = [
	"Qt5Bluetooth", "Qt5DBus", "Qt5Designer", "Qt5Designer", "Qt5Help", "Qt5Location",
	"Qt5Multimedia", "Qt5MultimediaWidgets", "Qt5Network", "Qt5Nfc", "Qt5OpenGL",
	"Qt5Positioning", "Qt5PositioningQuick", "Qt5Qml", "Qt5QmlModels", "Qt5QmlWorkerScript",
	"Qt5Quick", "Qt5Quick3D", "Qt5Quick3DAssetImport", "Qt5Quick3DRender",
	"Qt5Quick3DRuntimeRender", "Qt5Quick3DUtils", "Qt5QuickControls2", "Qt5QuickParticles",
	"Qt5QuickShapes", "Qt5QuickTemplates2", "Qt5QuickTest", "Qt5QuickWidgets", "Qt5Sensors",
	"Qt5SerialPort", "Qt5Sql", "Qt5Test", "Qt5TextToSpeech", "Qt5WebChannel", "Qt5WebSockets",
	"Qt5WebView", "Qt5Xml", "Qt5XmlPatterns"
	]
	for qt5Item in delQt5:
	qtItem = qt5Item.replace("Qt5", "Qt")
	unlinkIfFound(os.path.join(binDir, qt5Item+".dll"))
	unlinkIfFound(os.path.join(pyQt5Dir, qtItem+".pyd"))
	unlinkIfFound(os.path.join(pyQt5Dir, qtItem+".pyi"))
	deleteFolder(os.path.join(bindDir, qtItem))
	delList = [
	os.path.join(binDir, "opengl32sw.dll"),
	os.path.join(qt5Dir, "qml"),
	os.path.join(plugDir, "geoservices"),
	os.path.join(plugDir, "playlistformats"),
	os.path.join(plugDir, "renderers"),
	os.path.join(plugDir, "sensorgestures"),
	os.path.join(plugDir, "sensors"),
	os.path.join(plugDir, "sqldrivers"),
	os.path.join(plugDir, "texttospeech"),
	os.path.join(plugDir, "webview"),
	]
	for delItem in delList:
	if os.path.isfile(delItem):
	unlinkIfFound(delItem)
	elif os.path.isdir(delItem):
	deleteFolder(delItem)

I may just make a Qt cleanup function in setup.py for it some other time.

[Ryex]

Just tested the dmg from the last packaging action on my ventura VM. 91MB, seems to work fine. ^-^

[vkbo]

Just tested the dmg from the last packaging action on my ventura VM. 91MB, seems to work fine. ^-^

Excellent. Then I'll merge this. I'm trying to find a way to properly run the workflow. Unfortunately GitHub doesn't have a manual setting like GitLab does.

[vkbo]

Hah, I cracked it. I managed to get the on: workflow_dispatch to work. I just needed to add a mock workflow to the default branch, and it showed up in my Actions tab. I can then run the workflow on any branch I want.

By the way, my solution to the texlive/qt-linguist issue was to build the assets on a Linux runner first, and then download those into the MacOS runner for making the packages.

Edit: The problem with the run on tag approach is that when I get to apply the tag, the release is complete and merged, so if there is an issue with the build here, it's too late to fix. I need to run the build on the main or patch branch after the release PR has been merged, but before I tag it.

[Ryex]

Smart!

Glad I was able to help out with this. I'm sure there are at least some users looking forward to a proper bundle release.

Now you just need flatpak and you'll be effectively everywhere (i've been personally useing my flatpak build both on my desktop and to get it on my older laptop)