Infrastructure: improve build type handling

[SlySven]

Brief overview of PR changes/additions

Codifies the "type" of the Mudlet build to a single enum class instead of several bool flags and removes duplicate code to determine what value(s) they/it should have.

Motivation for adding to Mudlet

Simplification and removal of duplicate code. Also preparation wanted as part of solving problem with updating current Windows builds with the CI/CB produced "installer".

Other info (issues closed, discussion etc)

This is the first step in the resolution I am attempting for #7313.

[add-deployment-links[bot]]

Hey there! Thanks for helping Mudlet improve. :star2:

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/6b4ade/Mudlet-4.19.1-testing-pr8582-7bd768d4-linux-x64.AppImage.tar (commit 7bd768d4)
• osx intel: https://make.mudlet.org/snapshots/a20ebd/Mudlet-4.19.1-testing-pr8582-7bd768d4-x86_64.dmg (commit 7bd768d4)
• osx arm: https://make.mudlet.org/snapshots/28d1cd/Mudlet-4.19.1-testing-pr8582-7bd768d4-arm64.dmg (commit 7bd768d4)
• windows 64 bit: https://make.mudlet.org/snapshots/8e1a7b/Mudlet-4.19.1-testing-pr8582-7bd768d4-windows-64.zip (commit 7bd768d4)

No need to install anything - just unzip and run. Let us know if it works well, and if it doesn't, please give details.

[ZookaOnGit]

conflict, not building, switching to draft

[vadi2]

https://github.com/SlySven/Mudlet/pull/94

[SlySven]

https://github.com/Mudlet/Mudlet/pull/8582#pullrequestreview-3544822735 isn't quite correct IMHO.

This preserves the current behavior where releaseVersion = mAppBuild.isEmpty() is independent of whether the updater is compiled in.

In the context for the mudlet::BuildType Release DOES describe the behaviour needed by the code with regard to the functionality needed to perform updates - Linux packagers are expected to put something in MUDLET_VERSION_BUILD so that their builds are identified as something packaged into their distribution - for example if Debian ever returned to including Mudlet I would expect them to use a value like -deb12u1. However the functionality is convoluted in that the WITH_VARIABLE_SPLASH_SCREEN which was intended to make Mudlet always show the standard splash-screen would also be needed to make such a packaged build look like the "Release" one from us for the end-user - but for it to rely on their distribution specific updating mechanism rather than our (not in their case) built-in one.

I am actively considering changing WITH_VARIABLE_SPLASH_SCREEN to WITH_BUILD_BRANDING and using THAT to control both the (now only normally visible on the "About Mudlete" dialogue) splash screen AND the icon used for the Mudlet application itself (when NOT set to a NO value).

I am also recognising that I (well, we collectively) need to document all the WITH_XXX - and possibly other build "control" variables in the Wiki... :grinning:

[vadi2]

Linux packagers are expected to put something in MUDLET_VERSION_BUILD

I haven't heard of this before, and I don't think any package managers do this right now. Not sure why should we start obligating them to do it either.

I recommend fixing the logic bug introduced in the PR.

[SlySven]

Linux packagers are expected to put something in MUDLET_VERSION_BUILD

I haven't heard of this before, and I don't think any package managers do this right now. Not sure why should we start obligating them to do it either.

I recommend fixing the logic bug introduced in the PR.

The instruction has been there right from the blooming start :angry: - see 19a60d6c5ec05aa04fc6e692996fdfcf72b329b4 from 2017:

+# if you are distributing modified code, it would be useful if you
+# put something distinguishing into the MUDLET_VERSION_BUILD environment
+# variable to make identification of the used version simple
+# the qmake BUILD variable is NOT built-in
+BUILD = $$(MUDLET_VERSION_BUILD)
+isEmpty( BUILD ) {
+# Leave the value of the following empty for a release build
+# i.e. the line should be "BUILD =" without quotes
+BUILD = "-dev"
+}