Re: gradle reboot -- 2024W49 update
Good day,
Some news about the ongoing work on Gradle packaging:
Le 2024-12-02 19:43, sre4ever@free.fr a écrit :
The build progressed a bit and now fails on the outdated Groovy
Last week the build progressed some more and now (using --continue)
generates 78 of the 83 (86 minus 3 dropped) jars that are expected in
the binary distribution (that's almost 94%). Some Groovy issues were
solved by copypasting some newer Groovy source code right into the
project; that's indeed temporary and only necessary until Groovy gets
updated, and I plan to take care of that right after Gradle.
Now the build fails on Kotlin issues. These are going to be tougher
(getting it to build is one thing, getting it to actually work is
another thing) and my current plan to try to use the version that is
currently in Debian is likely to be a dead end for reasons already
stated on this list. I already had to drop the new declarative DSL as it
is not (yet?) needed for rebuilding Gradle (I didn't check for Kotlin
though) and makes use of many new features that were possibly added to
Kotlin as part of the collaboration between Gradle and JetBrains. What
remain are the regular kotlin-dsl and some parts of core-configuration
written in Kotlin, which are all necessary for core features and
rebuilding both Gradle and Kotlin.
I will see this week how far I can go with this plan. The alternative
would be to upgrade Kotlin at the same time, with similar (but a bit
more complicated) bootstrapping techniques.
Which brings us to the crucial subject of bootstrapping: I now have a
(non-functional) PoC of how I plan to proceed, which is basically to
make it possible to rebuild Gradle with a plain old Makefile [1],
automatically generated from Gradle build scripts, to be updated with
every new release and committed to the repository as part of the
packaging sources. For the rebootstrap this would go as follows
(assuming that all issues that would prevent Gradle from working are
already resolved):
- maintainer uses a binary distribution of Gradle from upstream to build
a first-stage patched Gradle and to generate the Makefile; that build
will not be used and is only necessary to correctly generate the
Makefile
- maintainer rebuilds a first stage patched Gradle using the Makefile
- maintainer builds a second stage patched Gradle using the
Makefile-built Gradle, check that it works (test suites), check that it
generates the same Makefile as the binary distribution, eventually
checks and investigates for differences in binaries against the
first-stage build with binary distribution
- maintainer commits packaging updates
- for the CI (or anybody else after the package is published) to rebuild
the package, debian/rules checks the version of Gradle that is currently
installed on the system; if the version is not known (i.e. successfully
tested) to be compatible (and this is probably going to be a very
restricted set of versions close to the one being built), d/rules will
build a first-stage Gradle using the pre-generated Makefile, then
(re)build the target Gradle using a temporary installation of the
first-stage Gradle.
As usual, comments and contributions are very welcome.
Cheers,
[1]:
https://salsa.debian.org/jpd/gradle/-/blob/upgrade-to-8.11.1-wip/debian/gradle.Makefile
— this Makefile is not useable as is, but you get the idea
--
Julien Plissonneau Duquène
Reply to: