Mac crt1.10.5 errata

Yeah

Clean Mac - five hour wipe + re-install everything. Not even got an SVN client on it ATM. Only Laz/FPC code is release 2.0.8/3.2.0 - i.e. it ain’t me…

People don’t test anything properly these days (when I were a lad…)

I’ve never actually got as far as an iOS/Android deploy other than using tests so I wanted to see what (if any) support mobile has.

I’m going thru the iOS tests section ATM but project needs a desktop for Win/Mac/Linux.

Just about to try building castle-engine on Mac 64 using 3.2.0…

I’d intended to have mobile variants along-side desktop versions. I started this using Delphi Rio but switched to Lazarus when I found out Delphi is more of a work-in-progress re CGE.

Delphi actually does have a widget set for iOS + Android and they’ve also got app tethering (a feature I desire). Sadly the community version of Delphi has terms that are basically “Write stuff but as soon as you make any cash pay us before anyone else” and the Linux support is only for their most expensive products.

No pod…

sudo gem install cocoapods?

Compiled library for iOS in castle-engine-output/ios/libcastle_spine_ios.a
Packaging project "castle_spine" for target "ios" (platform: iOS).
Generated CastleDataInformation.xml.
Project data contains 5 directories, 21 files, total (uncompressed) size 1.15 MB.
Exception "Exception":
Cannot find "pod" on environment variable $PATH. Make sure "pod" is installed and $PATH is configured correctly

Close but missing freetype lib for iOS (and I presume Mac)

At least I got an XCode project for 2d_dragon_spIne

OpenGLES depreciation warning of course…

Attempt at OSX - guessing switches from casle-engine --help

castle-engine package --os=macos --cpu=x86_64
The combination of operating system "macos" and processor "x86_64" is not possible (or not supported by FPC)

Yes :slight_smile: See iOS Services · castle-engine/castle-engine Wiki · GitHub .

We automatically link with freetype on iOS. And the “freetype” service is automatically added to your project if we find any ttf/otf files in the data, see https://github.com/castle-engine/castle-engine/blob/master/tools/build-tool/data/ios/services/freetype/README.md .

Attempt at OSX - guessing switches from casle-engine --help

If you want to compile for macOS, use --os=darwin.

I’m not sure why --os=macos doesn’t work, I’ll check it. All FPC documentation and docs always used darwin.

You can also actually just skip the --os and --cpu. By default build tool builds for the current platform, so if you have it precompiled for darwin/x86_64, then the default target is also darwin/x86_64. So just do castle-engine compile.

Note that the default backend on macOS is CASTLE_WINDOW_XLIB, which is far from perfect (you and your users need to install XQuartz). See macOS | Manual | Castle Game Engine . Basically, we miss a TCastleWindowBase backend using Cocoa (we have one using WinAPI, using GTK, using X11… but not Cocoa). The solution to have TCastleWindowBase using Cocoa is using Lazarus and alternative_castle_window_based_on_lcl.lpk package. See macOS | Manual | Castle Game Engine . So actually in this one case (desktop macOS) the default build tool result is not perfect. Adding a Cocoa backend for TCastleWindowBase is a TODO in CGE.

As for --os=macos: Ah, yes.

This refers to the classic macOS operating system, i.e. versions up to macOS 9. This is commonly called “classic macOS”, https://en.wikipedia.org/wiki/Classic_Mac_OS . FPC and various open-source tools call it just “macOS” instead of “classic macOS”, because for a long time this seemed to be the naming of Apple, that instead called the new system “Mac OS X” (“Darwin” being the actual kernel). Later Apple decided to bring back the name “macOS” for latest versions of the system, thus the old version should now be called “classic macOS” but I guess the naming in FPC (or GNU tools?) never got updated.

So

  • --os=darwin means the new macOS (aka Mac OS X)

  • --os=macos means the “classic macOS” that probably nobody uses anymore (and was never tested with CGE).

I updated castle-engine --help output to make it clearer. It will now show:

castle-engine: Build and package Castle Game Engine programs.

[....]
                        
  --os=<os>             Set the target operating system for which we
                        build/package.
                        This is ignored if you used --target=<target>, with
                        <target> being something else than "custom".
                        Available <os> values: 
[....]
                          macos (classic MacOS, that ended with MacOS 9)
                          darwin (modern macOS 10.x, caled also Mac OS X)
[....]

I was compiling 2d_dragon_spine following the instructions.

castle-engine package --target=ios --ios-simulator

Opened the xcodeproj in XCode - tried to run in simulator - linker error for freetype

Got OSX compiling eventually, this one did a linker error for X11 (yet to read links)

castle-engine package --os=darwin --cpu=x86_64

X11 link error (I’ll go read in a mo)

Linking code/castle_spine
ld: library not found for -lX11
An error occurred while linking
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/local/bin/ppcx64 returned an error exitcode
Exception "Exception":
Failed to compile

You should open the file .xcworkspace, not .xcodeproj.

See iOS · castle-engine/castle-engine Wiki · GitHub : “”“If there’s a file with .xcworkspace extension in that directory, open it in XCode. Otherwise, open the file with .xcodeproj extension (this will always be present).”“”

See also the iOS Services · castle-engine/castle-engine Wiki · GitHub : “”“” You should no longer open the project using my_project_name.xcodeproj file. This will not work, as the libPods... library will not be built in this case. Instead, open and run in Xcode the my_project_name.xcworkspace file (it is in the same directory as my_project_name.xcodeproj ). Using this will correctly build and run the project with dependencies.“”"

X11 link error (I’ll go read in a mo)

Indeed it’s written on macOS | Manual | Castle Game Engine :slight_smile: Add -k-L/usr/X11/lib/ to your FPC config file (/etc/fpc.cfg or ~/.fpc.cfg).

This is a very confusing statement. It implies it’s OK to open either while elsewhere it says DON’T open the xcodeproj file (didn’t get to that bit - went thru things step by step).

Surely, for the sake of clarity, the instructions should say Always open the xcworkspace, never open the xcodeproj.

This one got me and I’m not a complete novice (some people will be)

Happily Dragon Spine is now merrily flapping it’s wings in the iOS Simulator at present.

I see, now, what was happening before. You have to open the xcworkspace as that version also includes any dependencies while the xcodeproj omits them.

Hmm - Mac no longer has X11 (just spent ages trying to find X11 libs to modify fpc.cfg)

XQuartz is the only option they give. This implies that castle-engine Mac projects won’t be re-distributable.

On the iOS side of things I’m just getting the Apple account I use for distribution turned back on (it expired in Jan but nobody noticed, not even the bloke who gets the cash). When that’s back online I’ll see what happens with a dummy store submission project. Hopefully FPC will be fixed by then.

The sentence in docs was meant to be taken literally, like an instruction in code:

if FileExists('something.xcworkspace') then
  Open('something.xcworkspace')
else
  Open('something.xcodeproj');

:slight_smile:

In the future, you may not always have xcworkspace. It’s only created by CocoaPods. It just so happens that now it was easiest to just always link to freetype (yeah, I see in code – we just do it always on iOS now), thus every project always uses CocoaPods, and thus the section " Common notes for services using CocoaPods" on iOS Services · castle-engine/castle-engine Wiki · GitHub actually applies to all iOS projects compiled using CGE build tool.

I’ll think how to best express this in docs. I agree it can be confusing now.

XQuartz is the only option they give. This implies that castle-engine Mac projects won’t be re-distributable.

XQuartz is the X11 for macOS. Yes it’s the only way.

Surely you can distribute your application. You just have to instruct users that it’s an X11 application, thus they need to install https://www.xquartz.org/ too.

Or you can follow the mentioned way to compile TCastleWindowBase with LCL backend using Cocoa. This is the advised method in practice. The future is definitely a native TCastleWindowBase backend using Cocoa (without LCL), but it’s just not done in CGE yet :slight_smile:

On the iOS side of things I’m just getting the Apple account I use for distribution turned back on (it expired in Jan but nobody noticed, not even the bloke who gets the cash). When that’s back online I’ll see what happens with a dummy store submission project.

Note that you can deploy from XCode applications to your iPhone without being a registered (paying) developer, if the iPhone is physically (through USB cable) connected to your phone. So you can check iOS applications on an actual device without Apple account.

Hopefully FPC will be fixed by then.

You mean Lazarus? From what I can see, FPC 3.2.0 works OK for you. It’s the Lazarus compilation you have problems with.

XQuartz got Mac working although I modified the fpc.cfg instructions using

-k-L/opt/X11/lib/

This very minor change makes using XQuartz easy

Got reply about the SVN stuff. The upshot is that compiling fixes3.2 / fixes2.0 now looks like it worked with fpcupdeluxe which is using Laz 63429 ATM

And … Wow! Lazarus rebuilt the IDE - this is a first for 3.2.0 / 2.0.9. I’ve literally been doing very little else other than trying to get a working Mac Lazarus for weeks…

In the AM - CGE gets tested - it’s too late to spoil things now, up in the AM looking forwards to a working Mac installation.