[Pkg-pascal-devel] Castle Game Engine build tool

Sat Feb 6 15:36:52 UTC 2016

> image2pascal and texturefont2pascal are now in examples, right? We
> already use them during cge building.

Yeah. In CGE 5.3.0 I just clearly call them "tools", instead of
over-using the examples/ directory for them.

>
>> The 3rd tool is of particular importance. It can be used as a wrapper
>> around FPC compiler and some other tools to compile + package + install
>> the games. It can be used by Debian itself to compile future view3dscene
>> release, and many other CGE programs (every project using
>> CastleEngineManifest.xml can be compiled using the build tool).
>
> Does the packaging and installing follow the Debian rules for that? Is
> that configurable and/or optional? Otherwise, there is not much use
> within Debian.

The compile, package, install options are all separate. You can use
"compile" without "package". Some usage docs are on
https://github.com/castle-engine/castle-engine/wiki/Build-Tool .

I think the "compile" command could be useful for Debian packaging, it
could be used to compile view3dscene and any other future CGE
project:)

As for "package" and "install" commands: They are useless for Debian
packaging, indeed. They are only for simple usage/distribution outside
of Debian.

More info:

Packaging for standalone platforms is right now to zip or tar.gz.
Which is useful to just distribute your programs as an upstream. Some
reasons: By default "castle-engine package" makes sure to recompile
binary in release mode. And on Windows, the necessary DLL dependencies
are automatically added inside. Possibly more improvements will come
in the future.

The packaging process is very cool for an Android target, where you
get complete apk file at the end, that can be immediately installed on
a device.

But this packaging is not really useful for Debian packages. Maybe in
the future we could make automatic packaging to deb, but that's a song
of the far future (and I would ask a lot for your input then --- I
understand that such packaging should follow Debian standards,
otherwise it will not be of much use).

Similar notes for the "install" target. I doesn't actually do anything
now on standalone platforms. It is useful when developing a web plugin
(with --plugin) or when installing an Android application. See
https://github.com/castle-engine/castle-engine/wiki/Build-Tool#install
. *For now*, it's not useful at all on standalone platforms.

IOW, these "package" and "install" targets are useful for developers
using the engine, that's why giving them ready "castle-engine" binary
in /usr/bin would be useful. But they are not useful for Debian
packaging, at least not right now.

>
>> So, it would be great if Debian CGE package of 5.3.0 was including these
>> 3 tools precompiled. You can compile them using the xxx_compile.sh
>> scripts inside (if they are uncomfortable for any reason, please let me
>> know --- we can adjust them or provide alternatives). The binaries could
>> be installed in /usr/bin/ I guess.
>
> The texturefont2pascal_compile was so short, I just included the
> statement straight into our d/rules, which is a proper Makefile. That
> was easier. Unless the other compile scripts are more involved, I'll
> probably just do the same. However, if you could arrange everything from
> the top level Makefile and we wouldn't need to be bothered about
> anything, that would of course be great.

Is this useful: https://sourceforge.net/p/castle-engine/code/15116/ ?

It makes sure that the default "make" compiles all three tools.

And it adds "make install" command that installs the tools system-wide
(including the data of the build tool). It is configurable by standard
environment variables (PREFIX, DESTDIR, etc.). If it's useful for
Debian, it would be cool (then you would not need to be bothered if
another tool is added, or if I rearrange directory layout inside the
engine).

>
>> It includes precompiled libraries
>
> Ouch. In Debian we really frown upon that. Is this really needed?
> Wouldn't you consider it acceptable for your users when you ship TWO tar
> balls? One with the source of cge and one with other convenience other
> stuff? Debian likes to keep pristine tar balls from upstream, but I'll
> have to strip this if you ship it together.
>

I understand that it's problematic, I've read about it in the context
of other software:)

In our case, note that we *do not* bundle normal Linux libraries
there. We bundle the Windows precompiled libraries (and one
precompiled Android library). The reason is simple: these libraries
are quite crucial (e.g. libpng to read png files, OpenAL to play
sound), and getting them on some platforms (Windows, Android) is
cumbersome. Contrary to Linux (where all these libraries can be
installed using the package manager; besides some of them are really
standard, like libpng).

If need be, you can freely remove them in the Debian distribution, I
kind of expected this, that's why I mentioned this. They are only
required when packaging a game for Windows or Android (the latter only
if your game uses sound). Simply remove in your distribution the
directories

  castle_game_engine/tools/build-tool/data/external_libraries/

  castle_game_engine/tools/build-tool/data/android/integrated-components/sound/

The build tool will gracefully behave, everything will work Ok until
you try to package your game to Windows (or a game using sound to
Android), then you'll get a clear warning.

Our tar.gz really has to contain these libraries --- this makes
"package" to Windows or Android useful.

If need be, I can prepare alternative tar.gz, but that would really be
only for Debian packaging. For normal users, I would advice them to
download the full version anyway (to not complicate the download
links). So I'm not sure is it useful to strip them on my side? In
terms of file size, these libraries don't weight much (they are not
noticeable compared to our huge examples size:).

Regards,
Michalis

2016-02-05 20:58 GMT+01:00 Paul Gevers <elbrus at debian.org>:
> Hi Michalis,
>
> On 04-02-16 05:52, Michalis Kamburelis wrote:
>  The CGE 5.3.0 release will include a directory castle_game_engine/tools/
>> with programs that are useful for engine developers.
>>
>> 1. image2pascal
>> 2. texturefont2pascal
>> 3. build-tool (castle-engine binary)
>>
>> (In CGE 5.2.0, the build tool is just inside castle_game_engine/tools/,
>> without subdirectories, as far as I remember.)
>
> image2pascal and texturefont2pascal are now in examples, right? We
> already use them during cge building.
>
>> The 3rd tool is of particular importance. It can be used as a wrapper
>> around FPC compiler and some other tools to compile + package + install
>> the games. It can be used by Debian itself to compile future view3dscene
>> release, and many other CGE programs (every project using
>> CastleEngineManifest.xml can be compiled using the build tool).
>
> Does the packaging and installing follow the Debian rules for that? Is
> that configurable and/or optional? Otherwise, there is not much use
> within Debian.
>
>> So, it would be great if Debian CGE package of 5.3.0 was including these
>> 3 tools precompiled. You can compile them using the xxx_compile.sh
>> scripts inside (if they are uncomfortable for any reason, please let me
>> know --- we can adjust them or provide alternatives). The binaries could
>> be installed in /usr/bin/ I guess.
>
> The texturefont2pascal_compile was so short, I just included the
> statement straight into our d/rules, which is a proper Makefile. That
> was easier. Unless the other compile scripts are more involved, I'll
> probably just do the same. However, if you could arrange everything from
> the top level Makefile and we wouldn't need to be bothered about
> anything, that would of course be great.
>
>> It includes precompiled libraries
>
> Ouch. In Debian we really frown upon that. Is this really needed?
> Wouldn't you consider it acceptable for your users when you ship TWO tar
> balls? One with the source of cge and one with other convenience other
> stuff? Debian likes to keep pristine tar balls from upstream, but I'll
> have to strip this if you ship it together.
>
> Paul
>
>
> _______________________________________________
> Pkg-pascal-devel mailing list
> Pkg-pascal-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pascal-devel