KmyMoney Mac Os Build (ARM)

[francem at tiscali.it]

Hi,

let me start saying I'm not an experienced macOS developer,
but I used to be a Java developer, and I've been a happy KMyMoney user
on Mac for several years.

Being aware of KmyMoney build issue, I tried
to see whether, with AI/ChatGPT support, I could make a local build on a
fresh macOS environment.
I created a VM on UTM on an Apple Silicon Mac,
used Craft as the build tool, and with ChatGPT's support managed to
produce a working KMyMoney app and DMG package.

Beign able to complete
the build I tried the same approach to test locally the CI/CD pipeline
and found some fixes to be applied to let it work.
I'm not saying this
is perfect or the best but, with the following actions the pipeline
completed the build. 
Don't know if anyone in the Dev team could check
and verify but, please find hereafter a ChatGPT actions report:

This
document summarizes the changes and follow-up recommendations that
should be shared with the developers after reproducing the macOS ARM64
CI/CD build locally. It focuses on the concrete fixes that unblock the
pipeline, the exact files involved, and why each change is necessary for
automated builds. 

The local reproduction showed a sequence of failures
and recoveries: 

	* 

libs/zlib failed because the blueprint still
requested zlib-1.3.1.tar.xz, which now returns 404.  
	* 

After
updating zlib to 1.3.2, the dependency chain progressed, but
libs/gwenhywfar required a macOS ARM compile workaround for arm_acle.h. 

	* 

After gwenhywfar succeeded, the main project configure failed
because the macOS bundle install rule for the kmymoney executable was
incomplete.  
	* 

With that corrected, the full build completed
successfully and produced macos-arm-clang/Applications/KDE/kmymoney.app.


-------------------------

FILE:
craft-clone/blueprints/libs/zlib/zlib.py 

RELEVANT AREA: setTargets()
and the version-specific patch/digest blocks around the 1.3.1 / 1.3.2
entries. 

OBSERVED LOCAL BEHAVIOUR: the pipeline tried to download
https://www.zlib.net/zlib-1.3.1.tar.xz and received HTTP 404. After
changing the blueprint to 1.3.2, the tarball downloaded successfully and
the archive was valid. 

The blueprint should use 1.3.2 as the default
target instead of 1.3.1. The relevant changes are: 

	* 

Update the
target list so the supported release set includes 1.3.2 instead of
1.3.1.  
	* 

Update the targetDigests entry to match the 1.3.2 tarball.

	* 

Set defaultTarget = "1.3.2".  
	* 

Remove the
zlib-1.3.1-20240818.diff patch from the 1.3.2 patch list.   

The
pipeline failed at the very first dependency fetch because the version
hardcoded in the blueprint no longer exists upstream. That makes the CI
job deterministic but broken: every run repeats the same 404 until the
blueprint is updated. 

The local reproduction proved that
zlib-1.3.2.tar.xz exists, downloads cleanly, and passes archive
validation. That means the change is not speculative; it is a direct fix
for the CI artifact source. 

This is the highest-priority upstream
change. It is a pipeline blocker and should be merged first because
every later build stage depends on libs/zlib.


-------------------------

FILE: kmymoney/CMakeLists.txt 

RELEVANT
AREA: the install(TARGETS kmymoney ...) block around the line reported
by CMake, approximately line 204 in the local checkout. 

OBSERVED LOCAL
BEHAVIOUR: CMake stopped with:  

install TARGETS given no BUNDLE
DESTINATION for MACOSX_BUNDLE executable target "kmymoney" 

The build
then aborted during the configure stage, before any compile or package
install step could complete. 

Add a macOS bundle destination to the
install rule for the kmymoney executable. The missing clause is:


BUNDLE DESTINATION ${KDE_INSTALL_BUNDLEDIR}

The install(TARGETS
kmymoney ...) block should include a bundle destination alongside the
runtime/library destinations already used by the project. 

On macOS,
kmymoney is built as a MACOSX_BUNDLE application. CMake requires an
explicit bundle destination when installing a bundle target. Without it,
configure fails before the build can continue. This is not a runtime
issue; it is a packaging/install rule issue that stops the CI job during
the configure phase. 

The local build completed successfully after
adding the bundle destination, and the final artifact was installed as:


macos-arm-clang/Applications/KDE/kmymoney.app 

That confirms the
destination is correct for the KDE macOS layout. 

This is a
source-level fix in the project CMake files, not a Craft workaround. It
should be treated as a real CI/CD compatibility fix for macOS.


-------------------------

FILE LOCATION: no upstream source file was
identified during the local session; this was handled as a
build-environment workaround. 

OBSERVED LOCAL BEHAVIOUR:
libs/gwenhywfar failed during the Qt-related compile step because Qt 6
headers on macOS ARM64 reached qyieldcpu.h, where __yield() was not
declared. The error message pointed to: 

error: implicitly declaring
library function '__yield' with type 'void ()' 

Adding -include
arm_acle.h to the C++ compile flags allowed the gwenhywfar build to
complete successfully. 

For the macOS ARM64 pipeline, inject the
include only in the environment that builds gwenhywfar or the affected
dependency group, rather than globally for every package. 

A
conservative approach is: 

	* 

apply the workaround only on macOS
ARM64 jobs;  
	* 

scope it to the dependency build stage that needs it;

	* 

avoid making it a permanent global flag if it can be limited to
the specific package or platform.  

The dependency chain stalled before
KMyMoney itself could be configured. Without the workaround, the
pipeline never reaches the project build stage. Once the flag was added,
gwenhywfar completed and the build progressed to the main project.


This is likely a platform-specific CI environment issue rather than a
KMyMoney source defect. The important part for developers is that macOS
ARM64 builds currently need an additional compile-time include to
satisfy the Qt-related ARM intrinsic reference.


-------------------------

After the above changes and workaround, the
local macOS ARM64 build reached the final packaged application
successfully. 

The final successful artifact path was:


macos-arm-clang/Applications/KDE/kmymoney.app 

This confirms that the
pipeline blockers were resolved in sequence: 

	* 

zlib version
mismatch and dead download fixed.  
	* 

gwenhywfar ARM64 compile issue
worked around.  
	* 

KMyMoney macOS bundle install rule corrected.  
	*


Full build completed and installed successfully.  


-------------------------

The three items to communicate are: 

	*


craft-clone/blueprints/libs/zlib/zlib.py 

	* 

update the supported
release from 1.3.1 to 1.3.2  
	* 

update the digest for 1.3.2  
	*


remove the obsolete zlib-1.3.1-20240818.diff patch from the 1.3.2
block  
	* 

reason: upstream 1.3.1 tarball now returns 404 and blocks
CI immediately  

	* 

kmymoney/CMakeLists.txt 

	* 

add BUNDLE
DESTINATION ${KDE_INSTALL_BUNDLEDIR} to the install(TARGETS kmymoney
...) rule  
	* 

reason: macOS bundle installation failed during
configure because CMake requires a bundle destination for MACOSX_BUNDLE
executables  

	* 

macOS ARM64 build environment / Craft configuration


	* 

apply -include arm_acle.h only where needed for the gwenhywfar
build path  
	* 

reason: gwenhywfar failed on Qt 6 ARM64 because
__yield() was not declared by the default include set 


-------------------------

The local validation established the
following facts: 

	* 

zlib-1.3.2.tar.xz downloads successfully and the
tarball contents are valid.  
	* 

gwenhywfar passes once the ARM ACLE
header workaround is present.  
	* 

kmymoney configures and builds
successfully after adding the macOS bundle destination.  
	* 

The final
application bundle is produced under KDE's macOS application path. 


Hope this could help to fix the Mac Os Pipeline,
Marco

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20260414/15ae6ade/attachment.htm>