[Pkg-pascal-devel] Castle Game Engine 6.0 release in Debian

[Michalis Kamburelis]

"2017-03-12 20:18 GMT+01:00 Paul Gevers <elbrus at debian.org>:
>>   It would be best if the Debian (binary) package installed these
>> tools in a precompiled version, placed in /usr/bin/.
>
> I'll want to ship them and they probably warrant a separate package. Do
> you have a name in mind for the tools package? castle-game-tools?
> castle-game-engine-tools?
>

"castle-game-engine-tools" sounds good.

"castle-game-tools" could be a little unclear, as we have a game
called "The Castle" in the repository
https://github.com/castle-engine/castle-game . So, "castle-game-tools"
could be taken as "the tools for that game".

BTW, it's your decision, but are you sure that the tools need a
separate package? Developers using the engine will often want to
install both castle-game-engine core (Pascal units) and
"castle-game-engine-tools", my documentation advices it often as a
nice way to build games with data.

And non-developers don't install the engine (as the engine is compiled
statically, like most Pascal stuff, for now; so the end-user doesn't
need to install any Castle Game Engine libraries to play games done
using CGE).

>
>> I hope that this information will be useful when packaging new version
>> of Castle Game Engine and view3dscene in Debian. Please ask if
>> anything is unclear, or could be done better upstream:)
>
> Lintian warns me rightfully that the source of cge has multiple jar
> files. These files are considered pre-build. I noticed one jar could be
> found in the Debian archive (gradle-wrapper.jar from the
> libgradle-plugins-java package; didn't check yet if they are identical),
> but can you tell me where the other jars come from (preferably the
> source and how to generate them, .... well... you know the drill, sorry).
>

Ups...., my bad. Most of these jars were not supposed to be present in
the released archive. They are *not* open-source, and their
redistribution terms are not very permissive (see
https://github.com/castle-engine/castle-engine/wiki/Android-Project-Components-Integrated-with-Castle-Game-Engine
; their creators *want* you to use them and you can distribute
applications with them, but there's no general permission to
redistribute them freely). This applies to:

tools/build-tool/data/android/integrated-components/heyzap/app/libs/heyzap-ads-sdk.jar
tools/build-tool/data/android/integrated-components/heyzap/app/libs/chartboost.jar
tools/build-tool/data/android/integrated-components/heyzap/app/libs/adcolony.jar
tools/build-tool/data/android/integrated-components/chartboost/app/libs/chartboost.jar
tools/build-tool/data/android/integrated-components/startapp/app/libs/StartAppInApp-3.2.2.jar
tools/build-tool/data/android/integrated-components/giftiz/app/libs/GiftizSDK_1.5.0.jar

Please remove them from the sources in Debian.

I have fixed my release script, so they will disappear from future CGE
releases, and I added checking this to the "release checklist". The
next release (6.2) should happen soon, and have this fixed (and if it
will not happen fast, I'll release a bugfix 6.0.2 release soon).

The only jar files that should be present are these:

tools/build-tool/data/android/integrated/gradle/wrapper/gradle-wrapper.jar
tools/build-tool/data/android/base/gradle/wrapper/gradle-wrapper.jar

These files are committed and distributed, as advised by the Gradle
developers. See

https://docs.gradle.org/current/userguide/gradle_wrapper.html

"""
The Wrapper is something you should check into version control. By
distributing the Wrapper with your project, anyone can work with it
without needing to install Gradle beforehand. Even better, users of
the build are guaranteed to use the version of Gradle that the build
was designed to work with.
""""

> One other thing. I try to generate the files in auto_generated_node_helpers, but when I run the following
> $ ./generate_x3d_nodes_to_pascal ../components/*.txt

The full command should be

./generate_x3d_nodes_to_pascal ../components/*.txt
../../../../../cge-www/htdocs/x3d_extensions.txt

It is inside the
src/x3d/nodes_specification/generate_x3d_nodes_helpers/generate_x3d_nodes_to_pascal_run.sh
script. The script assumes that you have a cge-www repository (
https://github.com/castle-engine/cge-www ) cloned, as a sibling of the
castle-engine directory.

Hm, I see that this may be uncomfortable for you. Sorry -- I did not
think much when writing this, you're probably the first person besides
me to run the "./generate_x3d_nodes_to_pascal" :)

Workaround for now: Get the attached x3d_extensions.txt . Place it
alongside the generate_x3d_nodes_to_pascal sources, and then run it
like

./generate_x3d_nodes_to_pascal ../components/*.txt x3d_extensions.txt

Then the output will be exactly equal to what is distributed in the zip/tar.gz.

(Due to unrelated problem, x3d_extensions.txt has to be processed
last, that's why you can't just copy it inside the "components"
dir...)

(An exception to this is the file x3dnodes_x3dprototypeinstance.inc,
that can be removed, it's not used (leftover from previous runs of my
script; I improved it now to clear previous output first).)

I have fixed it all in the engine on GitHub of course. There is now a
simple file ..../components/CastleEngineExtensions.txt , and you just
call

./generate_x3d_nodes_to_pascal ../components/*.txt

and it regenerates everything correctly. So, engine 6.2 will have it
fixed cleanly.

> Files under /usr/bin should have a valid man-page in Debian. Do you have
> them, or do these binaries have a good --help option, or other way to
> generate them?

There are no man-pages, I'm afraid. I can help you create them. At
least, most tools respond to --help nicely:

- The build tool responds to --help nicely, and has more documentation
on https://github.com/castle-engine/castle-engine/wiki/Build-Tool
- castle-curves responds to --help nicely, and has more documentation
on https://github.com/castle-engine/castle-engine/wiki/Curves-tool
- image-to-pascal and texture-font-to-pascal respond to --help nicely.
- sprite-sheet-to-x3d shows usage when run without parameters. I fixed
it now in GitHub to also show it when run with --help.

Best regards,
Michalis