CGE in Delphi GetIt package manager

[michaliskambi]

In short: we want this :) So that Delphi users can install CGE from GetIt.

The current way to install Castle Game Engine is to download CGE from https://castle-engine.io/download and then

• either manually build Delphi packages (in packages/delphi/) and optionally extend the Delphi paths to point to all CGE sources
• or use Delphinus for this, https://castle-engine.io/download#delphinus

The goal is to enable people to

• easily compile applications using TCastleControl, that is a component you can drop on VCL and FMX form, https://castle-engine.io/control_on_form
• compile CGE applications using TCastleWindow, which is our recommended approach for games that don't need VCL / FMX and rely completely on CGE UI components.
• Make it possible by easily installing CGE from GetIt, make CGE discoverable for Delphi devs by being present in GetIt.

Our current Delphi package setup is just 1 design-time-only package castle_engine.dpk (see https://github.com/castle-engine/castle-engine/tree/master/packages/delphi ). But we know we'll make it more complicated, in particular branch split-delphi-design-time-package already has a split into 2 packages: https://github.com/castle-engine/castle-engine/tree/split-delphi-design-time-package/packages/delphi to address #498 .

@peardox @checkdigits Let's track coordination about GetIt here.

[peardox]

Sure thing. I'm just checking out split RTL+Design branch to see how that does - current test platform = 10.4.2 (had it handy)

Might be an idea to get Serge in here too (already mailed him)

Oh, 10.4.2 test build just failed :( Investigation time... [dcc32 Fatal Error] castle_engine_design.dpk(36): E2202 Required package 'castle_engine' not found

I guess this is why I test thoroughly tho :)

[michaliskambi]

@peardox Please let's keep this ticket focused about GetIt integration. It will be difficult to follow, esp. for other people, if we bring here discussion from other threads.

[peardox]

I've just been looking at Skia for ideas on GetIt for CGE. This package includes an IDE Helper 'Enable Skia' that configures an end project to include it's required DLLs. This seems like an obvious thing for CGE to do so you don't get situations like #489 as the 'optional' libraries could be configured to be included when a project is built. While only Win32/64 is currently supported the Deployment keys this kind of plug-in adds to the project make it easier to deploy to other platforms as well.

I also note that Skia sets up a SKIADIR delphi-only environment variable (I'm not sure if GetIt is performing this step at present). Assuming GetIt does this then we can have a CGEDIR that contains the required libraries for any platforms CGE4Delphi eventually supports.

It is also noteworthy that Skia uses the SKIADIR to referense it's sources and built dcus. This implies that the use of a CGEDIR would allow DCU build ourput to reside there as well as Source enabling Search Path, Browsing Path, {output}{platform}{config} to all be automatically configured

I'll got and try out the non-IDE Helper parts of this concept out as it should provide good insight into the possibilities

[peardox]

Quoting an email from Serge regarding GetIt...

According to the installation. GetIt can perform almost all installation actions which each user does. GetIt can install the package using multiple different actions (as you described before) or execute an external installer - it's up to you. As for the suffix - we can create different Getit entries for 10.4 and 11 versions. For each version I will install appropriate bpl.

For the beginning - I need a submission from you - because I need texts, image, license info and some beginning info about the installation process. We can adjust installation during submission - no worries :).

So, essentially the stuff I describe above appears to be easy (a candidate installation method was descrbed - the msg is in response). Additionally GetIt can, if we desire, also make the version-dependant projects (not that I'm sure this is needed)

[michaliskambi]

Status update about this to anyone that is looking to this task:

• This is still very much on our TODO list.

• We (Castle Game Engine devs) are focusing on Delphi a lot in recent years, I get a lot of feedback that users are happy with it (and I got to speak about Delphi in many places recently -- https://castle-engine.io/conferences ). And GetIt is the way to be exposed to most Delphi developers.

• Right now this waits for me to finish the Delphi/Linux branch (finalize last tasks, merge to master) as we know it will make necessary changes to our packages organization (since e.g. VCL is not available on Linux, naturally).

• After this, I hope to release Castle Game Engine 7.0-alpha.3

• And then submit to GetIt.

[michaliskambi]

Right now this waits for me to finish the Delphi/Linux branch (finalize last tasks, merge to master) as we know it will make necessary changes to our packages organization (since e.g. VCL is not available on Linux, naturally).

Let me expand this a little actually (thanks @peardox ):

Our Delphi/Linux port brings various improvements that are in general opening Castle Game Engine to be more cross-platform with Delphi.

• One thing is better Delphi package organization, as mentioned above. We must account for the fact that VCL is only for Windows.

• Another is usage of dglOpenGL, which is cross-platform OpenGL header (unlike Delphi built-in OpenGL headers that are only for Windows). Although https://github.com/SaschaWillems/dglOpenGL actually also supports for Delphi only Windows, but it is possible to extend it (and we already did, for Delphi/Linux) rather easily.

• Delphi/Linux also brings more FireMonkey usage underneath the TCastleWindow. That is, on Delphi/Windows, our TCastleWindow is using directly WinAPI (because we can, and it works most reliably, and is then equal to FPC). But on Delphi/Linux, TCastleWindow is using FireMonkey (with platform-specific code only to initialize GL context, e.g. using GTK3 on Linux). It also shares more code with TCastleControl ( https://castle-engine.io/control_on_form ). The end result of this is that it is easier to make both TCastleWindow and TCastleControl work with all possible platforms with Delphi.

• After Delphi/Linux, I expect that Delphi/Android will follow, as a popularly-requested target .

[peardox]

Considering the latest build are now more feature rich with the numerous additions such as C++ support, IDE extension and Linux added as a supported platform would the current version at least close to submissable? (as I think it's fairly good now)
If nothing else an updated progress statement would seem useful to others who read this

[michaliskambi]

We want to make 7.0-alpha3 release ASAP and then go with GetIt submission indeed.

[peardox]

When we get to that milestone I can test it on all supported versions (10.2 - 12.0) inc minor release variants in that case prior to submission as this is the most likely way to discover any hidden quirks

[michaliskambi]

When we get to that milestone I can test it on all supported versions (10.2 - 12.0) inc minor release variants in that case prior to submission as this is the most likely way to discover any hidden quirks

Thank you, that will be much appreciated as always. For what it's worth, I did test 12.0, 11.3 and 10.2.3 Delphi versions (with regards to our new packages and design-time menu "Tools -> Castle Game Engine"; with regards to Linux platform, I only tested on Delphi 12.0 and 11.3. That is, 10.2.3 is tested only to build for Win32 and Win64. )

[peardox]

I believe FMX Linux can be tested on all versions even if Getit is broken (still) by using the official FMXLinux trial package which is listed as ... Support of Delphi 10.2.x, 10.3, 10.4, 11 (same as us though they forgot to add 12). Note that this will allow testing on as low as 10.2.0 (from memory that one was problematical last time I tried it)

Regardless, after a full QA cycle, we'll know the supported release list exactly