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

[Paul Gevers]

Hi Michalis,

Thanks for your extensive explanation.

On 03/18/17 10:09, Michalis Kamburelis wrote:
> "> 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:)

Fine with me, whatever does the right thing®.

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

Agreed. One package it is for now.

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

Whow... makes me wonder how the ecosystem works. Just so you understand
my position. Among other reasons, for security purposes we want to avoid
convenience copies embedded in packages. I am also active in the
JavaScript area of Debian and embedded copies are a mess. So from the
distribution point of view, the way forward is to use the distribution
version. If a higher version of the file is required, I can help the
maintainer of that package to package a higher version (in experimental
for now). On the cge side of things, we can lock the version to
something specific, than at least "we" would know when we need to
upgrade. But I see your point as upstream clearly. So, if we treat
libgradle-plugins-java as a library, it appears to have a very unstable API?

So, if it is only this file, maybe we can ship it, but then I need to
have the source. Can you point me to it (and would you have an idea on
how to create .jar files)?

Extremely ugly work-around for dependencies of the run time binary
(still requires a working version in Debian) is to do the copying during
building. Maybe with a simple autopkgtest or build time test we could
detect broken Debian versions.

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

Great. Really great.

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

That would be great, but I am unsure if I have the time ($RL).

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20170318/8d1e2448/attachment.sig>