Re: [hatari-devel] Hatari macOS builds

Am 26.04.2023 um 22:32 schrieb Thomas Huth <th.huth@xxxxxxxxx>:

Am Wed, 26 Apr 2023 18:36:47 +0200
schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:

I appended a patch that makes it possible to automate the build process quite a bit. It might need some refinement, like only copy frameworks, if they were found and add some additional frameworks as mentioned.

Thanks a lot for the patch ... but I was still hoping that one of the macOS
guys here on the list could come up with a ready patch based on yours that
does all that additional stuff (i.e. take the libraries/frameworks into
account that have been found)... in the current shape, I think it's not
ready for commit yet (e.g. it should still be possible to compile Hatari
without PNG, but currently it's hardcoded there).

These commands were used from the root directory of the sources to create the distributable executable:
#cmake .
#make

Oh, now that's interesting, so you are *not* using the "Xcode" generator
for building macOS release apps? That's surprising, I somehow thought that
"cmake -G Xcode" would be required for building a proper app bundle...?

#install_name_tool -change /opt/local/lib/libz.1.dylib /usr/lib/libz.1.dylib src/hatari.app/Contents/MacOS/hatari
#codesign --force -s - src/hatari.app/Contents/MacOS/hatari

... and this codesign line also looks quite different to the one that the
Xcode generator was trying to execute before I disabled signing there.

Ok, so here's another try, with your patch (partially) applied and with the
standard generator instead of the Xcode one, and with your codesign line
added to the build script:

https://cirrus-ci.com/task/4689992333656064

Chris, Bob, could you please give that build a try, too?

Thanks,
Thomas

My patch explained (some things can be done in a different way, others are strongly recommended):

diff -ru a/CMakeLists.txt b/CMakeLists.txt

--- a/CMakeLists.txt 2023-04-23 07:38:11

+++ b/CMakeLists.txt 2023-04-25 18:53:56

@@ -1,5 +1,16 @@

cmake_minimum_required(VERSION 3.3 FATAL_ERROR)

—> It makes sense to move this up in any case.

+# Set build type to "Release" if user did not specify any build type yet

+# Other possible values: Debug, Release, RelWithDebInfo and MinSizeRel

+if(NOT CMAKE_BUILD_TYPE)

+ set(CMAKE_BUILD_TYPE Release)

+endif(NOT CMAKE_BUILD_TYPE)

—> These can be defined while invoking cmake. It needs to be defined before calling project().

+IF (CMAKE_BUILD_TYPE STREQUAL "Release")

+ set(CMAKE_OSX_ARCHITECTURES "x86_64;arm64" CACHE STRING "Target architectures" FORCE)

+ set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "Target Min 10.13" FORCE)

+ENDIF (CMAKE_BUILD_TYPE STREQUAL "Release")

project(Hatari C)

enable_testing()

@@ -13,12 +24,6 @@

include(CheckCCompilerFlag)

include(DistClean)

include(CheckTypeSize)

—> I recommend to move this up at least as already mentioned.

-# Set build type to "Release" if user did not specify any build type yet

-# Other possible values: Debug, Release, RelWithDebInfo and MinSizeRel

-if(NOT CMAKE_BUILD_TYPE)

- set(CMAKE_BUILD_TYPE Release)

-endif(NOT CMAKE_BUILD_TYPE)

# set(CMAKE_VERBOSE_MAKEFILE 1)

diff -ru a/src/CMakeLists.txt b/src/CMakeLists.txt

--- a/src/CMakeLists.txt 2023-04-23 07:38:11

+++ b/src/CMakeLists.txt 2023-04-25 19:01:58

@@ -94,6 +94,9 @@

add_executable(hatari MACOSX_BUNDLE ${GUIOSX_RSRCS} ${GUIOSX_DOCS} ${SOURCES} ${GUIOSX_SOURCES} ${FRAMEWORKS})

set_target_properties(hatari PROPERTIES MACOSX_BUNDLE_INFO_PLIST

${CMAKE_CURRENT_SOURCE_DIR}/gui-osx/Info-Hatari.plist)

—> These are absolutely necessary for correct linking. I strongly recommend to add this to Hatari.

+ set_target_properties(hatari PROPERTIES INSTALL_RPATH

+ "@executable_path/../Frameworks")

+ set_target_properties(hatari PROPERTIES BUILD_WITH_INSTALL_RPATH TRUE)

set(MACOSX_BUNDLE_ICON_FILE Hatari.icns)

if(CMAKE_GENERATOR MATCHES "Xcode")

set(BUNDLE_CONTENTS ${CMAKE_CURRENT_BINARY_DIR}/\${CONFIGURATION}/Hatari.app/Contents)

@@ -103,12 +106,15 @@

# Create Hatari.app bundle

add_custom_target(osx_bundle_dirs

COMMAND mkdir -p ${BUNDLE_CONTENTS}/Resources

—> It makes sense to create the Frameworks folder inside the application bundle. No adverse effects possible.

- #COMMAND mkdir -p ${BUNDLE_CONTENTS}/Frameworks

+ COMMAND mkdir -p ${BUNDLE_CONTENTS}/Frameworks

COMMAND mkdir -p ${BUNDLE_CONTENTS}/MacOS

COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/gui-osx/${MACOSX_BUNDLE_ICON_FILE}

${BUNDLE_CONTENTS}/Resources/${MACOSX_BUNDLE_ICON_FILE}

# Copy Localized .nib and help to Bundle

COMMAND cp -R ${CMAKE_CURRENT_SOURCE_DIR}/gui-osx/*.lproj ${BUNDLE_CONTENTS}/Resources/

—> This can be done manually or with some post build script.

+ # Copy Frameworks to Bundle

+ COMMAND cp -R ${SDL2_LIBDIR} ${BUNDLE_CONTENTS}/Frameworks/

+ COMMAND cp -R ${PNG_LIBRARY} ${BUNDLE_CONTENTS}/Frameworks/

COMMAND mkdir -p ${BUNDLE_CONTENTS}/Resources/HatariHelp

COMMAND cp -R ${GUIOSX_DOCS} ${BUNDLE_CONTENTS}/Resources/HatariHelp/

#COMMAND mkdir -p ${BUNDLE_CONTENTS}/Resources/fr.lproj/HatariHelp