all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Philip McGrath <philip@philipmcgrath.com>, 47153@debbugs.gnu.org
Subject: [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2.
Date: Tue, 16 Mar 2021 08:37:56 +0100	[thread overview]
Message-ID: <6e49888aaab2d2b2284d198eca51d0b9944be613.camel@student.tugraz.at> (raw)
In-Reply-To: <20210315225302.6597-1-philip@philipmcgrath.com>

Hi,

Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
> -      (sha256 (base32
> "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
> +      (sha256
> "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
You're inadvertently stripping away base32.

> -      (sha256 (base32
> "1q5i8pf4cdfjsj6r2k1rih7ljbfggyxdng2p2fvsgarzihpsin2i"))
> +      (sha256
> "01jnvw8qw33gnpzwrakwhsr05h6b609lm180jnspcrb7lds2p23d")
Same here.

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

> +                          ;; 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.

> +         ;; 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.

> +               (setenv "CC" "gcc")
This should be determined via cc-for-target.

> +               (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
needed for chez to function?  (Even if it was, it would then need to be
part of the "out" output.)  I personally doubt this; if you need stex
itself for your purposes, you can try packaging it later.

> +                    (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.

> +                    (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.

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

Regards,
Leo





  parent reply	other threads:[~2021-03-16  7:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15  8:42 [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging Philip McGrath
2021-03-15 10:32 ` Leo Prikler
2021-03-15 18:03   ` Philip McGrath
2021-03-15 18:28     ` Leo Prikler
2021-03-15 21:53       ` Philip McGrath
2021-03-15 22:21         ` Leo Prikler
2021-03-15 22:53           ` [bug#47153] [PATCH v2 1/3] gnu: chez-scheme: Update nanopass to 1.9.2 Philip McGrath
2021-03-15 22:53             ` [bug#47153] [PATCH v2 2/3] gnu: chez-scheme: Update stex Philip McGrath
2021-03-15 22:53             ` [bug#47153] [PATCH v2 3/3] gnu: chez-scheme: simplify packaging Philip McGrath
2021-03-16  7:37             ` Leo Prikler [this message]
2021-03-16 20:19               ` [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2 Philip McGrath
2021-03-16 21:09                 ` Leo Prikler
2021-03-19 18:24                   ` [bug#47153] [PATCH v3 1/3] " Philip McGrath
2021-03-19 18:24                     ` [bug#47153] [PATCH v3 2/3] gnu: chez-scheme: Update stex Philip McGrath
2021-03-19 18:24                     ` [bug#47153] [PATCH v3 3/3] gnu: chez-scheme: simplify packaging Philip McGrath
2021-04-05 10:02                     ` [bug#47153] [PATCH] " Ludovic Courtès
2021-04-05 14:20                       ` bug#47153: " Leo Prikler
2021-03-20 16:06                   ` [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2 Philip McGrath

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=6e49888aaab2d2b2284d198eca51d0b9944be613.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=47153@debbugs.gnu.org \
    --cc=philip@philipmcgrath.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.