Delphi package needs installing for both packages?

[peardox]

This is somewhat unintuative - the Win32 Release versions of castle_engine + castle_engine_design Both require INSTALLING

But castle_engine it RTL only...

castle_engine_design has nothing in it's CONTAINS - installing it registers the package but no components

IMHO castle_engine_design should have a very short register procedure that registers the components and castle_engine should not have the resister

This issue was discovered by installing CGE on a properly clean (no prior anything other than license) 10.2.0

[michaliskambi]

The solution is that castle_engine_design package should depend on castle_engine .

The Register cannot be moved to just castle_engine_design, as the castle_engine_design is design-time only (depends on designide Delphi packahe), and so has to be only for Win32.

And, conclusion from https://github.com/castle-engine/castle-engine/issues/498 is that that Register of the components has to be in package that has, as target platforms, all that we support (so Win32 and Win64 now). Otherwise, the component would be grayed out for non-Win32 platforms.

Thank you, I'll look into this along with https://github.com/castle-engine/castle-engine/issues/498 .

[peardox]

My concern here is FMX - i.e. any non-Windows OS

I'd imagine that enabling a Linux version would be the simplest non-Windows (but also non-CE) version to get running

As VCL + FMX are both in castle_engine then getting a TCastleComponent on a Linux form seems at least problematic owing to VCL?

Other platforms will, I imagine, require more effort than Linux but once Linux works then Mac, iOS and Android would presumably be simplified - at least conceptually. The percieved benefit being that once Linux works CE becomes a viable target for non-Windows (except Linux)

[peardox]

I just did an install on 11.3CE with disasterous results

The build order is rather important - if you build 64 after 32 the 32-bit version gets over-written resulting in things not working correctly when placing a TCastleComponent on a form

I've updated the README at https://github.com/peardox/castle-engine/tree/cge-getit-test/packages/getit to reflect this

I'm wondering if altering the dproj to include $RELEASE for output will work - I'll give it a go (will need another clean VM to test properly)

[peardox]

My test this morning resulted in my DEVREL license going over limit - trying to get this sorted ATM. Anyway this forced me to do a proper wipe (it's compilcated - lots left behind if you do normal uninstall) of Delphi from main PC and install CE resulting in main PC with a fresh CE.

A nice side-effect of this was that I got to try out the changes I made to my README (above) and follow that to the letter

The result was a perfectly functioning CGE under 11.3CE which I tested with my basic tests and Eye_Of_Beholder (Better change title - Hasbro will sue you - it's "product identity" - https://www.thegamer.com/dungeons-dragons-monsters-copyright/)

Interestingly my little tests have an almost instantaneous compile while EOB goes and compiles CGE (yeah - we know why)

Possibly a nice to-do(-never) would be for Editor to check if you're using a GetIt package and thereby drop the CGE paths from the dproj? It'd make compilation a lot faster...

[peardox]

I collect old RPG games :)

[michaliskambi]

Along with https://github.com/castle-engine/castle-engine/issues/498 , this should be fixed.

Note that castle_engine_design is no longer empty (it contains castleinternaldelphidesignutils.pas that requires designide dependency).

As explained above, the castle_engine (not castle_engine_design) does the Register on both components -- this is necessary to make them available for both Win32 and Win64.