[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2.
From: |
Philip McGrath |
Subject: |
[bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2. |
Date: |
Tue, 16 Mar 2021 16:19:17 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 |
Hi,
On 3/16/21 3:37 AM, Leo Prikler wrote:
Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
- (sha256 (base32
"1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
+ (sha256
"16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
You're inadvertently stripping away base32.
I thought I'd read that explicitly calling base32 was redundant and no
longer recommended: is there a reason to keep it?
- (commit (string-append "v" version))))
+ ;; This commit includes a fix for which we would
+ ;; otherwise want to use a snippet.
+ ;; When there's a new tagged release,
+ ;; go back to using (string-append "v" version)
+ (commit "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
Could we then not cherry-pick this commit as a patch? Or is there more
needed?
We could, but the upstream history is simply v1.2.2 -> my patch -> Kent
Dybvig's merge commit accepting it. I thought doing it this way
clarified that it's not a Guix-specific patch that should stay around
indefinitely. Is there a reason to prefer cherry-picking it as a patch?
+ ;; pre-built bootfiles for unsupported
systems:
+ "boot/a6nt"
+ "boot/a6osx"
+ "boot/i3nt"
+ "boot/i3osx"
+ "boot/ta6nt"
+ "boot/ta6osx"
+ "boot/ti3nt"
+ "boot/ti3osx")))))))
What about pre-built bootfiles for supported systems? Do we still need
those? If we so, I don't think it is right to delete anything in boot;
if not we should delete it altogether.
Currently, you need a bootfile for your current system to bootstrap the
Chez compiler; once you have a running Chez, you can build bootfiles for
any system Chez supports (which is more systems than it includes in its
git repository for bootstrapping). The bootfiles you build will be
byte-for-byte identical to pre-built ones, if pre-built ones were
provided: Chez in fact builds them twice and errors if they aren't. So,
I'm not sure why we would want these files, which are over 20 MB and are
only useful for bootstrapping Chez on Windows or Mac OS. But if there is
a reason to want them, we can keep them!
+ ;; put these where configure expects them to be
+ (add-after 'unpack 'unpack-nanopass+stex
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+ (let ((patch-source-shebangs
(assoc-ref %standard-phases 'patch-source-
shebangs)))
I don't think you need patch-source-shebangs directly after unpack.
Those shebangs would be patched in their phase anyway – the only reason
we needed it before was because we delayed unpacking until configure.
Right, thanks for catching this!
+ (setenv "CC" "gcc")
This should be determined via cc-for-target.
Will do.
+ (apply invoke
+ "./configure"
+ flags)
This can very likely be one line. Also, it should probably be done via
configure-flags.
[outputs]: Add "stex"
I don't think an stex output is justified in and of itself, or is it
Oops, I'd actually removed the "stex" output, but I missed it in the
commit message.
+ (flags (if (assoc-ref inputs "ncurses")
+ flags
+ (cons "--disable-curses"
+ flags)))
+ (flags (if (assoc-ref inputs "libx11")
+ flags
+ (cons "--disable-x11"
+ flags))))
These will probably be detected by the build system itself, there's no
need for you to add them. If not, then it's up to the packager of
other variants to specify them, not you.
IIRC, Chez's build system errors without these flags if the library
isn't found. Also, I intend to be "the packager of the other
variants"—my primary motivation for sending these patches is to reuse as
much as possible for Racket's fork of Chez, rather than all of the messy
copy-pasting we're doing now. But see below …
+ (flags (list
+ (string-append "--installprefix=" out)
+ (string-append "ZLIB=" zlib-static
"/lib/libz.a")
+ (string-append "LZ4=" lz4-static
"/lib/liblz4.a")
+ "--nogzip-man-pages" ;; guix will do it
+ "--threads"))
This should be done via #:configure-flags.
Now that I think of it…
+ (replace 'configure
I don't think this is needed at all. At most, you should filter the
incompatible flags from configure-flags in some way, but you might also
want to patch configure, so that it swallows them.
I'm not enthusiastic about the idea of maintaining such a patch for two
variants of this custom configure script which accept different sets of
flags, but neither of which accepts *any* of the flags that would be
added by the 'configure phase from %standard-phases. That procedure
offers no way to interpose between its adding the flags and its invoking
the configure script, so I don't see a good alternative to replacing it.
In fact, I'd modeled my implementation on the one from %standard-phases,
which similarly has a big `let*` expression adding implicit phases based
on the inputs and outputs.
If you think it's important to support #:configure-flags, I could change
this implementation to accept them, in which case I'd be ok with leaving
out handling of --disable-curses and --disable-x11. But I think anyone
packaging a variant of Chez will need to be aware of its idiosyncratic
configure script.
Refactor 'install-doc' phase into 'build+install-stex' and
'build+install-doc'
'build+install' implies, that it should actually be two phases, build
and install. I already talked about install-stex, so you should only
refactor install-doc insofar as it is needed to accommodate changes in
the build system.
It could be two phases, but the current install-doc phase does, in fact,
also build the docs, in addition to installing them. (It actually
neglects to install the HTML release notes but installs two copies of
the PDF user's guide.) I'm ok with calling it install-doc if you prefer.
I guess I could even split it into two phases, but that seems like it
would just make things more complicated for no obvious benefit.
As I mentioned, build+install-stex actually just "installs" stex to a
temporary directory right now. I think I could probably skip it and rely
on Chez's on-the-fly compilation, but I didn't see a problem with doing
it this way.
-Philip
- [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging, Philip McGrath, 2021/03/15
- [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging, Leo Prikler, 2021/03/15
- [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging, Philip McGrath, 2021/03/15
- [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging, Leo Prikler, 2021/03/15
- [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging, Philip McGrath, 2021/03/15
- [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging, Leo Prikler, 2021/03/15
- [bug#47153] [PATCH v2 1/3] gnu: chez-scheme: Update nanopass to 1.9.2., Philip McGrath, 2021/03/15
- [bug#47153] [PATCH v2 3/3] gnu: chez-scheme: simplify packaging, Philip McGrath, 2021/03/15
- [bug#47153] [PATCH v2 2/3] gnu: chez-scheme: Update stex., Philip McGrath, 2021/03/15
- [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2., Leo Prikler, 2021/03/16
- [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2.,
Philip McGrath <=
- [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2., Leo Prikler, 2021/03/16
- [bug#47153] [PATCH v3 1/3] gnu: chez-scheme: Update nanopass to 1.9.2., Philip McGrath, 2021/03/19
- [bug#47153] [PATCH v3 3/3] gnu: chez-scheme: simplify packaging, Philip McGrath, 2021/03/19
- [bug#47153] [PATCH v3 2/3] gnu: chez-scheme: Update stex., Philip McGrath, 2021/03/19
- [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2., Philip McGrath, 2021/03/20