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

[Michalis Kamburelis]

"> Warning for your next upstream release, there is still a patch coming
> from me to fix the install target in your Makefile -> permissions and
> creation of directories if not existing yet (current version attached,
> but still needs testing).

Of course, looks good.

A minor note: I would use

  install -d $(BINDIR)

instead of

  if [ ! -d $(BINDIR) ] ; then mkdir -p $(BINDIR) ; fi

This makes it consistent with the rest of the "install" target, that
uses "install" utility. Also, it doesn't require checking with "if [ !
-d $(BINDIR) ]" first. Actually, "mkdir -p" also doesn't require it:)

>> 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).

> Ok, for now, I'll ship them with the fp-units. However, aren't some of
> the tools not useful outside cge and/or pascal even?

Hm, indeed, I didn't think about it earlier. The sprite-sheet-to-x3d
is useful for anyone dealing with spritesheets and X3D -- not
necessarily in the Castle Game Engine context. The other four
utilities are only for CGE developers (well, you can use castle-curves
and the build tool without the engine, but I don't think it is useful
for many people).

I *think* it's still a little better to put the utilities in the
single package with engine core, for simplicity, for now... But I'm
not certain anymore:) Your choice:) Maybe "sprite-sheet-to-x3d" will
just warrant a separate package some day.

> Because this file is also available in Debian, I really want to symlink
> to the version shipped by libgradle-plugins-java. Your version seems to
> me to be much older than the one in Debian, is that intensional?

The version of Gradle (2.14.1) that we use is intentional.

(Long explanation below, sorry!)

If you take the /usr/share/java/gradle-wrapper.jar from Debian's
libgradle-plugins-java, then you'll upgrade Gradle, and I'm afraid
it's not that painless. The Gradle version is tied with the "Android
Gradle plugin" version, and trying to combine incompatible versions
results in problems. See
https://developer.android.com/studio/releases/gradle-plugin.html#updating-gradle
for a table listing which "Android Gradle plugin" versions match which
Gradle versions.

You can see the current versions in CGE:
- Of the Android plugin in
castle-engine/tools/build-tool/data/android/base/build.gradle
- Of the Gradle in
castle-engine/tools/build-tool/data/android/base/gradle/wrapper/gradle-wrapper.properties

Currently, we use Android plugin version 2.1.3 with Gradle version 2.14.1.

When upgrading the Gradle version, you need to do all these things at once:

1. upgrade Gradle version.
2. upgrade "Android gradle plugin" version, which are part of the
Android tools in Google Android SDK.
3. and sometimes adjust the xxx.gradle files, that use commands
defined by the "Android gradle plugin". The new plugin versions are
not compatible with each other, unfortunately.

Moreover, to change a "difficult" task into "impossible", the Gradle
3.2.1 (in the latest Debian testing and unstable, see
https://packages.debian.org/search?keywords=gradle ) cannot be used at
all. It doesn't match any Android plugin version. Trying to use it
with Android plugin version 2.1.3 results in problems:

"""
org.gradle.api.internal.tasks.DefaultTaskInputs$TaskInputUnionFileCollection
cannot be cast to
org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection
"""

And if you try to fix it by upgrading the Android plugin version to
2.3.0, then you get another error:

"""
Minimum supported Gradle version is 3.3. Current version is 3.2.1. If
using the gradle wrapper, try editing the distributionUrl in
/tmp/castle-engine992943/gradle/wrapper/gradle-wrapper.properties to
gradle-3.3-all.zip
"""

So, the Gradle version 3.2.1, available in Debian testing and
unstable, cannot be used to build Android tools at all (it's too old
for Android plugin 2.1.3-2.2.3, and too new for Android plugin 2.3.0,
which is confirmed officially on
https://developer.android.com/studio/releases/gradle-plugin.html#updating-gradle
).

When the Debian Gradle will upgrade to 3.3, we can get back to this.

It could still be a little troublesome:

- It will make the CGE code closely tied to the Gradle version in
Debian. E.g. currently, Debian stable has Gradle 1.5, backports has
Gradle 2.10, testing and unstable have 3.2.1 (and in the future will
have Gradle 3.3). All these Gradle versions will require different
code (different xxx.gradle files) on the CGE side. It would be easier
for me to target a single Gradle version...

- This would pull the libgradle-plugins-java, with it's dependencies,
as dependencies of the Castle Game Engine, as far as I understand.
Which is only necessary to build Android applications, and it requires
anyway some tools outside of Debian (full Android SDK and NDK, and FPC
cross-compiler for Android). So it would warrant a comment in the
description like "This package suggests the libgradle-plugins-java,
ignore it if you're not interested in building Android applications".

Note: If we decide to follow this route in the future, then we can
simply remove the Gradle files from the CGE. The build tool can simply
call the "gradle" on $PATH, as installed by "gradle" package (which
uses "libgradle-plugins-java"). See the appropriate part of attached
"trying-to-use-debian-gradle.patch". No need to symlink the Gradle
files in this case.

See the trying-to-use-debian-gradle.patch for my tests around this.

> I recommend to maintain only one version. And if you are going to create
> the man-page from the help anyways, I'll do the same in Debian. As you
> know, I always want to build from the "preferred form for modification"

I initially wanted to write that, while help2man can create an
acceptable manual page, I can craft something better manually.

But, after a bit of experimenting, I can make the output of --help and
--version suitable both for humans and for help2man, and indeed this
is much better for maintenance. The new engine version includes a
couple of changes to make it as good as it can be, and the manual
pages can be generated by running "make" inside
castle-engine/doc/man/man1/ . I hope that this helpful:)

If you want to test it before release, you can grab the engine from
GitHub, see https://github.com/castle-engine/castle-engine/ .

Best regards,
Michalis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trying-to-use-debian-gradle.patch
Type: text/x-patch
Size: 1961 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20170318/25f07562/attachment.bin>