[bug#56604] [PATCH 0/8] Update Clojure to 1.11.1.

[Roman Scherer]

Hi Ludo,

here's the promised patch to follow up with the code duplication I
introduced in my previous patch.

I tested this by compiling Clojure which uses the Ant build system, and
by compiling clojure-tools-deps-alpha which uses the Clojure build
system. Both of the build systems now call the repack-jar function.

Could you have a look at it please?

A related question:

When I run the following commands after modifying the build systems they
run for quite some time, because they were compiling a ton (the jdk,
jetty) of things.

./pre-inst-env guix build clojure
./pre-inst-env guix build clojure-tools

I guess this is expected, since a change in a build system might affect
all packages being built with it. But I was wondering if there is a way
to force only building the packages specified on the command line. Does
such a thing exists?

I was wondering what is the most efficient way to quickly iterate on
changes to a build system, without recompiling the whole world for that
build system. How would you do that?

Thanks, Roman.

0001-build-system-Add-repack-jar-and-use-it-in-Ant-Clojur.patch
Description: Add repack-jar and use it in Ant & Clojure build systems

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> r0man <roman@burningswell.com> skribis:
>
>> This phase makes sure the timestamp of compiled class files is set to a later
>> point in time than the timestamp of the corresponding Clojure source files. 
>> If
>> the timestamps of the class and source files are the same, the Clojure
>> compiler will compile the sources again which can lead to issues. This 
>> problem
>> has been discussed here [1]. The suggested solution was to keep/adjust the
>> timestamps of the class files.
>
> Sounds reasonable.  It’s a bummer though that the whole phase is pasted
> from ant-build-system.scm, the only difference being the timestamps
> (1980 instead of 1970).
>
> I added a TODO comment in clojure-build-system.scm when applying the
> patch.  Could you follow up with a patch to factorize that?
>
>> Btw, I was a bit surprised that in Guix Clojure packages are AOT compiled. 
>> The
>> general wisdom in the Clojure community seems to be to avoid AOT compilation
>> when distributing libraries, and only AOT compiling Uberjars for final
>> deployment. Due to issues like I mentioned in clojure-instaparse.
>>
>> Are we sure that AOT compiling all Clojure source files by default is a good
>> idea, instead of just compiling user declared namespaces which Leiningen and
>> friends are doing? WDYT?
>
> Not much, but as you might have seen in ./etc/teams.scm, the project is
> finally being structured as teams.  There’s an opportunity for you to
> start a Clojure team and to take the lead!  :-)
>
> As a first step, I’d recommend getting in touch with people who have
> worked on ‘clojure-build-system’ and packaged things in the past.
>
>>   gnu: clojure-tools-cli: Update to 1.0.206.
>>   gnu: clojure-tools-gitlibs: Update to 2.4.181.
>>   gnu: clojure-tools-deps-alpha: Update to 0.14.1212.
>>   gnu: clojure-tools: Update to 1.11.1.1149.
>>   gnu: clojure: Update to 1.11.1.
>>   gnu: clojure-algo-generic: Fix test failing under AOT in Clojure 1.11.1.
>>   gnu: clojure-core-match: Update to 1.0.0.
>>   gnu: clojure-instaparse: Update to 1.4.12 (disabled AOT).
>
> I adjusted all the commit logs to follow our conventions; please
> consider doing this next time:
>
>   https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html
>
> The instaparse patch missed the hash update so I did that too.
>
> Thanks!
>
> Ludo’.

signature.asc
Description: PGP signature