[bug#54396,WIP] gnu: python-notmuch2: Fix build.

Hi Guix,

I'm (still) trying to fix a build failure I (unsuccessfully) reported
here: <https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00302.html>.

I've tried and produced a patch, but, somehow, I cannot make it work! :-(

```
+               (setenv "SHELL" (which "sh"))
+               (setenv "CONFIG_SHELL" (which "sh"))
```

I'm not sure those lines are required, but at this point I've just
copied/pasted code I found in an other package definition.


```
+               ;(invoke "./configure" (string-append "--prefix=" out)))))
+               (invoke "bash" "./configure" (string-append "--prefix=" out)))))
```

If I "just" invoke `./configure` I get an error code, but no error
message. I had to prepend `bash` to get the error message telling me
that `cc` and `gcc` were missing.


```
+  #:use-module (gnu packages commencement)
; […]
+    (native-inputs (list gcc-toolchain))
```

When I add `#:use-module (gnu packages commencement)` I get the following error
message I cannot decipher:

```
error: tcc: unbound variable
hint: Did you forget a `use-modules' form?

error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

; […]

Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f)'.
Backtrace:
In guix/store.scm:
   658:37 19 (thunk)
   1320:8 18 (call-with-build-handler #<procedure 7f3d04dabb70 at g…> …)
In guix/scripts/build.scm:
    499:2 17 (_)
In srfi/srfi-1.scm:
   673:15 16 (append-map _ _ . _)
   586:17 15 (map1 ((argument . "python-notmuch2") (build-mode . 0) …))
In guix/scripts/build.scm:
   519:31 14 (_ _)
In gnu/packages.scm:
    478:2 13 (%find-package "python-notmuch2" "python-notmuch2" #f)
    363:6 12 (find-best-packages-by-name _ _)
   293:56 11 (_ "python-notmuch2" _)
In unknown file:
          10 (force #<promise #<procedure 7f3d04634060 at gnu/packag…>)
In gnu/packages.scm:
   240:33  9 (fold-packages #<procedure 7f3d03cb34a8 at gnu/package…> …)
In guix/discovery.scm:
   159:11  8 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  7 (fold #<procedure 7f3d072f41e0 at guix/discovery.scm:1…> …)
In guix/discovery.scm:
   149:19  6 (_ _ ())
    116:5  5 (scheme-modules _ _ #:warn _)
In srfi/srfi-1.scm:
   691:23  4 (filter-map #<procedure 7f3d072f7f00 at guix/discove…> . #)
In guix/discovery.scm:
   124:24  3 (_ . _)
In guix/ui.scm:
    325:2  2 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f))'.
```

Any advice welcome!

Regards,

Hi Tanguy,

Am Dienstag, dem 15.03.2022 um 10:38 +0100 schrieb Tanguy Le Carrour:
> Hi Guix,
> 
> I'm (still) trying to fix a build failure I (unsuccessfully) reported
> here:
> <https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00302.html>
> .
> 
> I've tried and produced a patch, but, somehow, I cannot make it work!
> :-(
> 
> ```
> +               (setenv "SHELL" (which "sh"))
> +               (setenv "CONFIG_SHELL" (which "sh"))
> ```
> 
> I'm not sure those lines are required, but at this point I've just
> copied/pasted code I found in an other package definition.
> 
> 
> ```
> +               ;(invoke "./configure" (string-append "--prefix="
> out)))))
> +               (invoke "bash" "./configure" (string-append "--
> prefix=" out)))))
> ```
> 
> If I "just" invoke `./configure` I get an error code, but no error
> message. I had to prepend `bash` to get the error message telling me
> that `cc` and `gcc` were missing.
Instead of running configure, I suggest generating the
_notmuch_config.py on your own.  There are three variables you need to
define at the moment: NOTMUCH_INCLUDE_DIR and NOTMUCH_LIB_DIR need to
point to the already built notmuch, not the one being currently
unpacked, and NOTMUCH_VERSION_FILE can also point to an installed file
if possible; otherwise generate a dummy.

> ```
> +  #:use-module (gnu packages commencement)
> ; […]
> +    (native-inputs (list gcc-toolchain))
> ```
> 
> When I add `#:use-module (gnu packages commencement)` I get the
> following error
> message I cannot decipher:
> 
> ```
> error: tcc: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: googletest: unbound variable
> hint: Did you forget a `use-modules' form?
Such cascading error chains typically happen when a package is
malformed and the module it's in can't be compiled.  I'm not sure if
that's your fault or someone messed with the python module, but either
way, you shouldn't use gcc-toolchain for package definitions regardless
of whether it causes an error or not.  It is solely meant for users to
not complain that "gcc doesn't work!!!111!1!einself!" when installing
it into their profiles.


Cheers

Hi Liliana,

Thanks for reviewing!


Quoting Liliana Marie Prikler (2022-03-15 11:11:14)
> Am Dienstag, dem 15.03.2022 um 10:38 +0100 schrieb Tanguy Le Carrour:
> > I'm (still) trying to fix a build failure I (unsuccessfully) reported
> > here:
> > <https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00302.html>
> > .
> > 
> > I've tried and produced a patch, but, somehow, I cannot make it work!
> > :-(
> > 
> > ```
> > +               (setenv "SHELL" (which "sh"))
> > +               (setenv "CONFIG_SHELL" (which "sh"))
> > ```
> > 
> > I'm not sure those lines are required, but at this point I've just
> > copied/pasted code I found in an other package definition.
> > 
> > 
> > ```
> > +               ;(invoke "./configure" (string-append "--prefix="
> > out)))))
> > +               (invoke "bash" "./configure" (string-append "--
> > prefix=" out)))))
> > ```
> > 
> > If I "just" invoke `./configure` I get an error code, but no error
> > message. I had to prepend `bash` to get the error message telling me
> > that `cc` and `gcc` were missing.
> Instead of running configure, I suggest generating the
> _notmuch_config.py on your own.  There are three variables you need to
> define at the moment: NOTMUCH_INCLUDE_DIR and NOTMUCH_LIB_DIR need to
> point to the already built notmuch, not the one being currently
> unpacked, and NOTMUCH_VERSION_FILE can also point to an installed file
> if possible; otherwise generate a dummy.

Oh… oh… that's a brilliant idea, actually! How stupid of me not to have
thought about it right away!! ^_^'
Thaaaanks! I'll do that!


> > ```
> > +  #:use-module (gnu packages commencement)
> > ; […]
> > +    (native-inputs (list gcc-toolchain))
> > ```
> > 
> > When I add `#:use-module (gnu packages commencement)` I get the
> > following error
> > message I cannot decipher:
> > 
> > ```
> > error: tcc: unbound variable
> > hint: Did you forget a `use-modules' form?
> > 
> > error: googletest: unbound variable
> > hint: Did you forget a `use-modules' form?
> Such cascading error chains typically happen when a package is
> malformed and the module it's in can't be compiled.  I'm not sure if
> that's your fault or someone messed with the python module, but either
> way, you shouldn't use gcc-toolchain for package definitions regardless
> of whether it causes an error or not.  It is solely meant for users to
> not complain that "gcc doesn't work!!!111!1!einself!" when installing
> it into their profiles.

Ok, good to know. Thanks!


Regards,

Tanguy Le Carrour schreef op di 15-03-2022 om 10:38 [+0100]:
> When I add `#:use-module (gnu packages commencement)`

From (gnu packages commencement):

> ;;; To avoid circular dependencies, this module should not be
> imported
> ;;; directly from anywhere.

if it still needs to be used, you could look at how gnu-build-system
sort-of imports it anyway, indirectly.

Greetings,
Maxime.

Hi Maxime,


Quoting Maxime Devos (2022-03-15 17:04:19)
> Tanguy Le Carrour schreef op di 15-03-2022 om 10:38 [+0100]:
> > When I add `#:use-module (gnu packages commencement)`
> 
> From (gnu packages commencement):
> 
> > ;;; To avoid circular dependencies, this module should not be
> > imported
> > ;;; directly from anywhere.
> 
> if it still needs to be used, you could look at how gnu-build-system
> sort-of imports it anyway, indirectly.

A well-deserved RT*M! :-)
Thanks for pointing at! In my defence, I still haven't figured out how
to configure "go to definition" in my Emacs (works for Python, though!),
so navigating the code is still a bit painful.
…Yeah, I know, it's a lame excuse! ^_^'

Regards,