all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Roman Scherer <roman.scherer@burningswell.com>
Cc: 56604-done@debbugs.gnu.org
Subject: [bug#56604] [PATCH 0/8] Update Clojure to 1.11.1.
Date: Thu, 01 Sep 2022 11:09:11 +0200	[thread overview]
Message-ID: <87tu5r4g20.fsf@gnu.org> (raw)
In-Reply-To: <87zgg55wyq.fsf@burningswell.com> (Roman Scherer's message of "Mon, 15 Aug 2022 15:36:32 +0000")

Hi Roman,

(Catching up after vacation…)

Roman Scherer <roman.scherer@burningswell.com> skribis:

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

Awesome.

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

No, it doesn’t exist, because that would be building something
different.  In this case, building everything that depends on
‘ant-build-system.scm’ is unavoidable.

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

There’s no ideal solution as you’ll have to recompile the world anyway.

When changing build systems, I’d usually stare at my changes for quite
some time first, to make sure I don’t have to rebuild the world on the
next day because of a typo.  :-)

Then, for small local changes, I’d build just the bottom of the
dependency graph to check for breakage (in this case, making sure the
‘strip-jar-timestamps’ phase still works as intended).  Then we can let
ci.guix build the whole thing afterwards, and make sure nothing goes
wrong.

> From 756bfd3458ded38e1041ebb255c6b6ffe737732d Mon Sep 17 00:00:00 2001
> From: Roman Scherer <roman@burningswell.com>
> Date: Mon, 15 Aug 2022 15:29:25 +0000
> Subject: [PATCH] build-system: Add repack-jar and use it in Ant & Clojure
>  build systems
>
> * guix/build/ant-build-system.scm: Add repack-jar and use it in strip-jar-timestamps
> * guix/build/clojure-build-system.scm: Use repack-jar in reset-class-timestamps

Please use the ChangeLog format, specifying procedure/variable names and
their actual changes.

[...]

> +(define-public (repack-jar outputs repack-fn)
> +  "Unpack all jar archives, invoke repack-fn for each JAR with the directory
> +it has been unpacked to, and pack them again."

Instead of ‘define-public’, I’d move ‘repack-jar’ to #:export at the
top, like the other procedures.

But…

> @@ -206,13 +205,7 @@ (define (repack-archive jar)
>        (with-directory-excursion dir
>          (invoke "jar" "xf" jar))
>        (delete-file jar)
> -      ;; XXX: copied from (gnu build install)
> -      (for-each (lambda (file)
> -                  (let ((s (lstat file)))
> -                    (unless (eq? (stat:type s) 'symlink)
> -                      (utime file 0 0 0 0))))
> -                (find-files dir #:directories? #t))
> -
> +      (repack-fn dir)

Looking at the code, the only difference between the two repack
functions is the timestamp, right?  In that case, I’d lean towards
adding a #:jar-timestamp parameter to ‘strip-jar-timestamps’ (rather than
this ‘repack-fn’ argument) that’d be passed to ‘utime’.  The default for
#:jar-timestamp would be '(0 0 0 0); for Clojure we’d set the default
#:jar-timestamp in (guix build-system clojure) to:

  #:jar-timestamp (list early-1980 early-1980)

WDYT?

Thanks,
Ludo’.




  reply	other threads:[~2022-09-01  9:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-16 18:17 [bug#56604] [PATCH 0/8] Update Clojure to 1.11.1 r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 1/8] gnu: clojure-tools-cli: Update to 1.0.206.--- r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 2/8] gnu: clojure-tools-gitlibs: Update to 2.4.181.--- r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 3/8] gnu: clojure-tools-deps-alpha: Update to 0.14.1212.--- r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 4/8] gnu: clojure-tools: Update to 1.11.1.1149.--- r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 5/8] gnu: clojure: Update to 1.11.1.This patch updates Clojure to 1.11.1. It also adds the 'reset-class-timestamps r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 6/8] gnu: clojure-algo-generic: Fix test failing under AOT in Clojure 1.11.1 r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 7/8] gnu: clojure-core-match: Update to 1.0.0.--- r0man
2022-07-16 18:24 ` [bug#56604] [PATCH 8/8] gnu: clojure-instaparse: Update to 1.4.12 (disabled AOT).This patch updates clojure-instaparse to 1.4.12. Due to the following AOT r0man
     [not found] ` <handler.56604.B.165799563211388.ack@debbugs.gnu.org>
2022-07-17 18:14   ` [bug#56604] Acknowledgement ([PATCH 0/8] Update Clojure to 1.11.1.) Roman Scherer
2022-07-19 15:11 ` [bug#56604] [PATCH 0/8] Update Clojure to 1.11.1 Maxime Devos
2022-07-22 22:11 ` bug#56604: " Ludovic Courtès
2022-08-15 15:36   ` [bug#56604] " Roman Scherer
2022-09-01  9:09     ` Ludovic Courtès [this message]
2022-09-01 10:03       ` Maxime Devos
2022-09-02 10:12         ` Roman Scherer
2022-09-02  9:52       ` Roman Scherer
     [not found] ` <handler.56604.D56604.16585278756386.notifdone@debbugs.gnu.org>
2022-07-25 18:06   ` [bug#56604] closed (Re: bug#56604: [PATCH 0/8] Update Clojure to 1.11.1.) Roman Scherer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tu5r4g20.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=56604-done@debbugs.gnu.org \
    --cc=roman.scherer@burningswell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.