[Pkg-pascal-devel] New Castle Game Engine (7.0-alpha.3) and Castle Model Viewer (5.2.0) releases

[Michalis Kamburelis]

wt., 22 paź 2024 o 08:39 Abou Al Montacir <abou.almontacir at sfr.fr> napisał(a):
> > - I also considered changing our fpmake.pp to just search in
> > subdirectories using wildcard, i.e. add all src/xxx/*.pas -- for now
> > resigned, but maybe I'll do this in the future.
>
> Yes that can be a solution, but do we really need to keep fpmake?

Maybe indeed dropping fpmake.pp is reasonable in the future for CGE.

It *is* the least used build method, of all our supported build
methods, so indeed it is the one I'm most inclined to eventually
remove to make my life easier :) It is practically useful now for

- InstantFpc usage (
https://github.com/castle-engine/castle-engine/tree/master/examples/instantfpc
, https://wiki.freepascal.org/InstantFPC ), which is a cool thing but
not the "core" feature of CGE.

- and by you, i.e. Debian packaging scripts. Possible migration paths
for Debian would be adapting "castle-engine cache" workings (
https://castle-engine.io/build_tool#_cache ). This is basically doing
what you need, i.e. precompiles engine units. To
~/.config/castle-engine/cache/ , but this could be adapted for your
needs.

    (Note: you don't need to build-depend on Lazarus / lazbuild for
base CGE compilation.)

My main reason to keep FpMake is a hope (but not realized yet...) that
FpPkg ( https://wiki.freepascal.org/fppkg ) will become the
popular/standard way to distribute FPC packages. Like pip for Python,
npm for JS/Node.js etc. Alas, FpPkg didn't gain popularity, and FPC
devs don't seem inclined to use it much themselves (e.g. it was
proposed but rejected to host Pascal GTK 3 bindings as FpPkg package).
But if FpPkg ever becomes popular, then having fpmake.pp will be a
requisite to be there.

Anyhow, that's for the future :) At least for 7.0, I guess I'll keep fpmake.pp.

Regards,
Michalis