GNU bug report logs - #72925
Adding JPM package for Janet

Previous Next

Full log

View this message in rfc822 format

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Omar Bassam <omar.bassam88 <at> gmail.com>
Cc: Sharlatan Hellseher <sharlatanus <at> gmail.com>, 72925 <at> debbugs.gnu.org, Munyoki Kilyungi <me <at> bonfacemunyoki.com>, Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, Guillaume Le Vaillant <glv <at> posteo.net>, jgart <jgart <at> dismail.de>, Suhail Singh <suhailsingh247 <at> gmail.com>
Subject: [bug#72925] Adding JPM package for Janet
Date: Wed, 18 Sep 2024 12:16:28 -0400

Omar Bassam <omar.bassam88 <at> gmail.com> writes:

> Thank you for taking the time to look into my patch. Sorry, I'm new to Guix
> and to this workflow. So, forgive me if my questions look a bit naive:
> 1. What do you mean by reroll count for the patch?

Please refer to the man page of git-format-patch and look for
--reroll-count :

#+begin_quote
       -v <n>, --reroll-count=<n>
           Mark the series as the <n>-th iteration of the topic. The output
           filenames have v<n> prepended to them, and the subject prefix
           ("PATCH" by default, but configurable via the --subject-prefix
           option) has ` v<n>` appended to it. E.g.  --reroll-count=4 may
           produce v4-0001-add-makefile.patch file that has "Subject: [PATCH
           v4 1/20] Add makefile" in it.  <n> does not have to be an integer
           (e.g. "--reroll-count=4.4", or "--reroll-count=4rev2" are allowed),
           but the downside of using such a reroll-count is that the
           range-diff/interdiff with the previous version does not state
           exactly which version the new iteration is compared against.
#+end_quote

> 2. I looked at the copy-build-system documentation. I'm not sure how it can
> be used here. I'm not just updating the shebang. As you can already see in
> the patch, I'm doing a lot of string substitutions in the source code
> itself because some values are hard coded. That's why I preferred to use
> the trivial-build-system to have more control of what I need to substitute.

Based on my understanding of the patch you are copying files, updating
some references in files, and setting environment variables.  I believe
all of these are possible via the copy-build-system as well which is
described as:

#+begin_quote
  ;; Standard build procedure for simple packages that don't require much
  ;; compilation, mostly just copying files around.  This is implemented as an
  ;; extension of `gnu-build-system'.
#+end_quote

If you'd like to learn more, you can grep under ./gnu/packages and look
at some instances where it's used.  I don't have experience with the
trivial-build-system, which is why I wondered.

> +                    (setenv "PREFIX" %output)
> +                    (setenv "JANET_PREFIX" %output)
> +                    (setenv "JANET_LIBPATH" (string-append %output "/lib/janet"))
> +                    (setenv "JANET_MODPATH" (string-append %output "/lib/janet"))

What would be a way to test that the above is doing the "correct" thing?
Is there a sequence of steps that I can evaluate which will yield a
different outcome depending on whether or not the above accomplishes
what it intends to?  Put another way, what breaks when the above aren't
set (and how do I observe that failure)?

-- 
Suhail

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.