unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Steve George <steve@futurile.net>
To: guix-devel@gnu.org
Cc: r0man <roman@burningswell.com>,
	Reilly Siegel <mail@reilysiegel.com>,
	Maxime Devos <maximedevos@telenet.be>
Subject: Proposal to turn off AOT in clojure-build-system
Date: Mon, 19 Feb 2024 11:46:53 +0000	[thread overview]
Message-ID: <ZdM/rSucBwQr5/cl@t25sg> (raw)

Hi,

Guix's clojure-build-system turns on AOT compilation by default. I would like to advocate that 'as a distributor' we should *not* ship Clojure code AOT'd, so we should change the default.

This has been discussed previously. In #56604 r0man noted that AOT compilation should not be on by default [0], Reilly makes the same point in #53765 [1].

Maxime makes the point that where a compiler is available it should be used [2] and that if it doesn't work it's a bug:

  "if a Clojure library misbehaves when AOT-compiled, without additional context, that seems like a bug in the Clojure library to me (or the AOT-compilation code).

The perspective in the Clojure community is quite different from Guix's on a number of fronts. There's not much discussion about offline builds, reproducibility or code coming from Distributions. The internalised perspective is that you use the build tools to download libraries directly from Clojars (a Maven repo) and developers create a final uberjar for production usage Consequently, there is no specific statement saying 'Distributors should not AOT libraries' that I can point to. But, I would like to draw attention to this thread on Clojureverse as the best source I could find:

Alex Miller is the main community manager for Clojure, and is a maintainer of the core libraries, so his perspective is key. He notes that, AOT code is tied to *specific versions of Clojure*:

  "AOT'ed code is that it is inherently the product of a particular version of tthe Clojure compiler ... I would recommend NOT AOT compiling libraries" [4]

In the same thread thheller, who is the maintainer of the most popular ClojureScript tooling,  notes you cannot mix AOT and non-AOT libraries [5]:

    "you cannot just ship your library AOT compiles as it would also contain clojure.core. Clojure AOT current ... can not load clj files from .class files. So AOT produces the class files and will fail if one of the dependent classes is missing although the .clj file is present"

I believe this means that with AOT code on, any user who installs a different version of Clojure from the one that we used to AOT the libraries *may* have problems. And, that we can't have trees where some part is AOT'd but a dependency is not. Finally, there is no expectation in the Clojure community that this is a bug, consequently it will not be fixed. Therefore, we should change to default to AOT off.

What do people think, does this make sense?

Thanks,

Steve / Futurile

[0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56604#5
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53765#290
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53765#293
[4] https://clojureverse.org/t/deploying-aot-compiled-libraries/2545/6
[5] https://clojureverse.org/t/deploying-aot-compiled-libraries/2545/3
[5] https://gist.github.com/hiredman/c5710ad9247c6da12a99ff6c26dd442e


             reply	other threads:[~2024-02-19 11:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19 11:46 Steve George [this message]
2024-02-19 14:44 ` Proposal to turn off AOT in clojure-build-system Maxime Devos
2024-02-21 11:29   ` Steve George
2024-02-22 14:57     ` Maxime Devos
2024-02-22 15:33       ` Andreas Enge
2024-02-22 15:47         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-22 17:44           ` Maxime Devos
2024-02-23  2:13             ` Maxim Cournoyer
2024-02-22 17:12         ` Maxime Devos
2024-02-23 12:41           ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-23 16:49       ` Steve George
2024-02-19 18:13 ` Ryan Sundberg
2024-02-19 21:38   ` Carlo Zancanaro
2024-02-24  3:39 ` 宋文武
2024-03-09 22:27 ` Ian Eure
2024-03-12 12:12   ` Jean-Pierre De Jesus Diaz

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=ZdM/rSucBwQr5/cl@t25sg \
    --to=steve@futurile.net \
    --cc=guix-devel@gnu.org \
    --cc=mail@reilysiegel.com \
    --cc=maximedevos@telenet.be \
    --cc=roman@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).