Keep asd-systems for cl-* packages

  • Open
  • quality assurance status badge
Details
2 participants
  • Charles
  • Guillaume Le Vaillant
Owner
unassigned
Submitted by
Charles
Severity
normal
C
C
Charles wrote on 26 Nov 2022 05:09
(name . guix-patches@gnu.org)(address . guix-patches@gnu.org)
6QMfWfugHjXZbctaQwmVqNfGLUMeY0qN2DYheuYiV9DTvgHtkFUWrUU2aMBjC6foVSt51Jkuwd5YcIoI6QDpY1DQl7vn6sAOKZgVjfkPJyc=@proton.me
Greetings Guix patches!

From 990cb50b8ba49c2bf1787abdffa54318d285624c Mon Sep 17 00:00:00 2001
From: Charles <charles.b.jackson@protonmail.com>
Date: Thu, 24 Nov 2022 11:44:12 -0600
Subject: [PATCH] guix: asdf-build-system: Keep some package-arguments for cl-*
packages.

Specifically asd-system and asd-test-systems. Before theses were striped
out. Now they stay there as meta data not used by the build-system.

* guix/build-system/asdf.scm (package-with-build-system):
Remove #:asd-systems #:asd-test-systems from striped arguments.
---
guix/build-system/asdf.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Toggle diff (15 lines)
diff --git a/guix/build-system/asdf.scm b/guix/build-system/asdf.scm
index 74a3e47da1..2985f7f786 100644
--- a/guix/build-system/asdf.scm
+++ b/guix/build-system/asdf.scm
@@ -203,7 +203,7 @@ (define (new-inputs inputs-getter)
(define base-arguments
(if target-is-source?
(strip-keyword-arguments
- '(#:tests? #:lisp #:asd-systems #:asd-test-systems #:asd-operation)
+ '(#:tests? #:lisp #:asd-operation)
(package-arguments pkg))
(package-arguments pkg)))
--
2.38.1
C
C
Charles wrote on 8 Dec 2022 05:14
y318LPg_jXXPcPcsFoNhc-na22BwuViNRYMgrZ-Ly5UVapf3Z_hO0RUVvwQecb_k4oiB_RwUekSUBwZUwMfDCY5CzQk4vEYVVweAkFAFTV4=@proton.me
Hey Guillaume. Do you have an opinion on this. I'm asking since you were the only one who responded to the initial thread. Thanks for taking a look by the way.
G
G
Guillaume Le Vaillant wrote on 10 Jan 2023 14:05
(name . Charles)(address . Charles.b.jackson@proton.me)(name . 59592@debbugs.gnu.org)(address . 59592@debbugs.gnu.org)
87cz7mlbye.fsf@kitej
Hi,

The 'asd-systems' field contains the minimal subset of the ASDF systems
defined by a library that, when compiled, compiles all the systems of
the library.

For example, the ironclad package has many subsystems:
"ironclad/ciphers"
"ironclad/digests"
"ironclad/cipher/aes"
"ironclad/cipher/threefish"
"ironclad/digest/sha256"
"ironclad/public-key/ed25519"
...
but the 'asd-systems' field only contains "ironclad".

The mcclim package also has many subsystems:
"automaton"
"clim"
"clim-core"
"clim-core/frames"
"clim-core/system"
"drei-mcclim"
"esa-mcclim"
"mcclim-backend-common"
"mcclim-fonts"
"slim"
...
but the 'asd-systems' field only contains the top level ones, "mcclim",
"clim-examples" and "clim-debugger".

So you can't rely on the contents of 'asd-systems' to have a complete
list of the systems defined by a library.

You could get the full list by searching the for 'defsystem' forms in
the sources directly, with something like:

Toggle snippet (3 lines)
find sources -name "*.asd" -exec grep "(defsystem" {} \; | cut -d ' ' -f 2

But it would only work for systems not using the package-inferred-system
feature of ASDF.


In my files, I found a function (I don't remember where I got it from)
that can get all the dependencies of a loaded system, even the ones
using package-inferred-system. Maybe it could be modified to limit the
results to a specific library's source tree...
Attachment: get-dependencies.lisp
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCY71xOQ8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j/oaAD9Hi7gIFOPZwYWi7e8Y5TMSGAeZoxeyLSN+4JE
CBw4258A/RCHTL6HI+hapEylhWPBN6jOVK9l9N2V9NnEnIpMU7L3
=tCIh
-----END PGP SIGNATURE-----

C
C
Charles wrote on 20 Jan 2023 21:24
(No Subject)
(name . 59592@debbugs.gnu.org)(address . 59592@debbugs.gnu.org)(name . Guillaume Le Vaillant)(address . glv@posteo.net)
LAXnBfDNwRRdjRJ5mlEzriczZoGm_z6BhmYTPTtE9iTzxQJWn-a1bcxy7zpKoy5z_yzroMXl_l-VzZ-h9HRH_vSYESOEjhfLVRj4ZklxkJM=@proton.me
I didn't know that package-inferred-systems also coupled asdf systems in addition to packages and files. I'm not a fan of package-inferred-system if you couldn't tell.

What are your thoughts on a patch that would add all systems to #:asd-systems? I could use your program along with some manual filtering to filter it out. It is ideal to have the knowledge of all asd-systems of a project before loading it.
G
G
Guillaume Le Vaillant wrote on 28 Jan 2023 10:46
(name . Charles)(address . Charles.b.jackson@proton.me)(name . 59592@debbugs.gnu.org)(address . 59592@debbugs.gnu.org)
87h6wbarnx.fsf@kitej
Charles <Charles.b.jackson@proton.me> skribis:

Toggle quote (7 lines)
> I didn't know that package-inferred-systems also coupled asdf systems in addition to packages and files. I'm not a fan of package-inferred-system if you couldn't tell.
>
> What are your thoughts on a patch that would add all systems to #:asd-systems?
> I could use your program along with some manual filtering to filter it out. It
> is ideal to have the knowledge of all asd-systems of a project before loading
> it.

Adding everything to 'asd-systems' would be tedious. I think Guix
package definitions are not the right place to keep the complete list of
available ASDF systems (just like we don't keep the list of ".so"
C libraries in package definitions).

There's a file search functionality that is being developped (there's
some info about it in the guix-devel mailing list I think). Maybe it
could be used as a base for a script searching for ASDF systems.
-----BEGIN PGP SIGNATURE-----

iIUEAREKAC0WIQTLxZxm7Ce5cXlAaz5r6CCK3yH+PwUCY9T2cg8cZ2x2QHBvc3Rl
by5uZXQACgkQa+ggit8h/j+AwwD+PGtxGVcQlyhR/6YWrA0My7W+cWHBFuWSsR3v
QqI0GowA/100nR546XaIYLKKDSEJVzQ2L4RN804dHBefIJnlhmbD
=oSAa
-----END PGP SIGNATURE-----

C
C
Charles wrote on 28 Jan 2023 17:23
(name . Guillaume Le Vaillant)(address . glv@posteo.net)(name . 59592@debbugs.gnu.org)(address . 59592@debbugs.gnu.org)
fyrKwDCh0b0ikiYNOkwrQuetFSqsyHBnYWOgbE2L1cz8tLy3yVHzySL8YcUnc7FKyLK9iSFQbehdUi77bch-uzncdob1s-yL_HWJ4IqfsSI=@proton.me
Toggle quote (2 lines)
> Adding everything to 'asd-systems' would be tedious.

We can agree on that point.

Toggle quote (4 lines)
> I think Guix package definitions are not the right place to keep the
> complete list of available ASDF systems (just like we don't keep the
> list of ".so" C libraries in package definitions).

But where is a better place? I was planning to open up the conversation
about doing just that for C libraries ? (and executable binaries, and
python packages, and rust crates, and so on).
Toggle quote (4 lines)
> There's a file search functionality that is being developped (there's
> some info about it in the guix-devel mailing list I think). Maybe it
> could be used as a base for a script searching for ASDF systems.

Subject: "File Search".

I have a couple gripes with that approach:

1. It only searches for files (using a file database). This makes it hard to
differentiate searching between different types of files. This also makes it
hard to search for something like an asdf system which might not be associated
with a file on a 1 to 1 basis.

2. It only index the searchable stuff after building the packages. This raises
a whole lot of issues mentioned in that thread already (networking, privacy, etc.).
My approach would make the information available at the time of guix pull in the
package definition.
?