Improve ASDF build system for Common Lisp libraries

Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

Hi,

I've been working on some changes to the asdf-build-system for Common
Lisp libraries and programs:

 - Switching from compile-bundle-op to regular compile-op.
   Using the regular compilation operation of ASDF instead of bundles
   gives us automatic support for component-less systems and
   package-infered systems. It also makes possible having a working
   sbcl-cl-slime-swank package instead of having to propagate the
   cl-slime-swank source package.

 - Replacing the asd-file and asd-system-name keywords by asd-files and
   asd-systems.
   This allows listing several '.asd' files to read and several systems
   to compile in a Guix package definition. Therefore it is not
   necessary to make one Guix package per Common Lisp system anymore.
   For example, mcclim had to be split in dozens of packages, it is now
   just one package.

I just pushed these improvements on the wip-lisp branch.
Could some lispers try it and report if there are issues?

Thanks.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

Wow!  Impressive work!
Thanks for undertaking this behemoth endeavour, especially with the all
the lisp-xyz updates!

The code looks good to me at first glance.
I'm currently building everything, I'll let you know.

What do you think about the moving the SBCL / ECL definitions to package
outputs?
Of course, this can wait, we could do this as a second step if you think
it's a good idea.

I'll test SBCL- packages with Nyxt.  They use to break Nyxt
(sbcl-cl-webkit and sbcl-cl-cffi-gtk), I'll see if it works now.

I'll also see test sbcl-osicat.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 209 bytes --]

About Osicat: There are grovel left overs that could be removed.
The former build system used to do that automatically.  Maybe we can
restore this behaviour?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]


Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> What do you think about the moving the SBCL / ECL definitions to package
> outputs?

I thought about having the sources, SBCL compiled files and ECL compiled
files respectively in the 'out', 'sbcl' and 'ecl' packages outputs;
however I thought there could be issues in some cases.

For example, if a profile contained cl-xyz and cl-xyz:sbcl, and if the
user tried to load this xyz system in ECL, then I think ECL would try
to compile the system and write the compiled files to cl-xyz:sbcl and
fail because it is read-only. That's because cl-xyz:sbcl contains the
ASDF configuration indicating "the compiled files for cl-xyz are in
cl-xyz:sbcl", and ECL is going to read that configuration.

It might be possible to have smarter ASDF configuration files behaving
differently depending on the lisp implementation running, but I have not
investigated this for the moment.


> About Osicat: There are grovel left overs that could be removed.
> The former build system used to do that automatically.  Maybe we can
> restore this behaviour?

The former build system deleted everything in 'lib/common-lisp/' except
the bundle. We can't do that anymore because now the fasl files that we
have to keep are in a directory tree whose structure we can't really
predict. It depends how the sources are organized.
Maybe we could just add a 'cleanup-left-overs' phase in the definition
of the packages where some left-overs can be deleted.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 129 bytes --]

I've just tested Nyxt: it works with all inputs as SBCL packages!

Fantastic!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Katherine Cox-Buday]

Guillaume Le Vaillant <glv@posteo.net> writes:

> I've been working on some changes to the asdf-build-system for Common
> Lisp libraries and programs:

Thank you so much for these changes!

-- 
Katherine

Re: Improve ASDF build system for Common Lisp libraries

[Konrad Hinsen]

Am 12.09.20 um 11:36 schrieb Guillaume Le Vaillant:

> I've been working on some changes to the asdf-build-system for Common
> Lisp libraries and programs:

That sounds very promising, thanks for this substantial effort! I can't 
test this right now, but will do so as soon as possible.

Cheers,
   Konrad

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]


Guillaume Le Vaillant <glv@posteo.net> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>
>> About Osicat: There are grovel left overs that could be removed.
>> The former build system used to do that automatically.  Maybe we can
>> restore this behaviour?
>
> The former build system deleted everything in 'lib/common-lisp/' except
> the bundle. We can't do that anymore because now the fasl files that we
> have to keep are in a directory tree whose structure we can't really
> predict. It depends how the sources are organized.
> Maybe we could just add a 'cleanup-left-overs' phase in the definition
> of the packages where some left-overs can be deleted.

Actually, it looks like the files generated by the groveler can't be
removed. When doing '(asdf:load-system "osicat")', if these files are
not there cffi tries to generate them (and fails because the directory
is read-only).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

Guillaume Le Vaillant <glv@posteo.net> writes:

> Actually, it looks like the files generated by the groveler can't be
> removed. When doing '(asdf:load-system "osicat")', if these files are
> not there cffi tries to generate them (and fails because the directory
> is read-only).

The .so needs to be kept, the rest can be removed:

--8<---------------cut here---------------start------------->8---
$ tree /gnu/store/haz3msfmr9cnlnrfai29q5csinx8l5q3-sbcl-osicat-0.7.0-1.de0c18a/
/gnu/store/haz3msfmr9cnlnrfai29q5csinx8l5q3-sbcl-osicat-0.7.0-1.de0c18a/
├── lib
│   └── sbcl
│       ├── osicat.asd
│       ├── osicat--system.fasl
│       └── posix
│           └── libosicat.so
...
--8<---------------cut here---------------end--------------->8---

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Guillaume Le Vaillant <glv@posteo.net> writes:

> I thought about having the sources, SBCL compiled files and ECL compiled
> files respectively in the 'out', 'sbcl' and 'ecl' packages outputs;
> however I thought there could be issues in some cases.
>
> For example, if a profile contained cl-xyz and cl-xyz:sbcl, and if the
> user tried to load this xyz system in ECL, then I think ECL would try
> to compile the system and write the compiled files to cl-xyz:sbcl and
> fail because it is read-only. That's because cl-xyz:sbcl contains the
> ASDF configuration indicating "the compiled files for cl-xyz are in
> cl-xyz:sbcl", and ECL is going to read that configuration.
>
> It might be possible to have smarter ASDF configuration files behaving
> differently depending on the lisp implementation running, but I have not
> investigated this for the moment.

There is probably a way to tell where to load the libraries from, and
where to compile them.

By default, each compiler compiles to
~/.cache/common-lisp/$compiler_name-$compiler_version.

This is what ECL should do here.  The ASDF configuration should be so
that it does not change this  behaviour.

If you can't figure it out I can give it a shot.  Otherwise let's ask
the ASDF people.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]


Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> Actually, it looks like the files generated by the groveler can't be
>> removed. When doing '(asdf:load-system "osicat")', if these files are
>> not there cffi tries to generate them (and fails because the directory
>> is read-only).
>
> The .so needs to be kept, the rest can be removed:
>
> --8<---------------cut here---------------start------------->8---
> $ tree /gnu/store/haz3msfmr9cnlnrfai29q5csinx8l5q3-sbcl-osicat-0.7.0-1.de0c18a/
> /gnu/store/haz3msfmr9cnlnrfai29q5csinx8l5q3-sbcl-osicat-0.7.0-1.de0c18a/
> ├── lib
> │   └── sbcl
> │       ├── osicat.asd
> │       ├── osicat--system.fasl
> │       └── posix
> │           └── libosicat.so
> ...
> --8<---------------cut here---------------end--------------->8---

When I remove the groveler-generated files (except the .so) from
'lib/sbcl/osicat/posix/' like so:

--8<---------------cut here---------------start------------->8---
/gnu/store/1cps5zbqgj9lm108lc57zah5ap0a7gbk-sbcl-osicat-0.7.0-1.de0c18a/lib
└── common-lisp
    └── sbcl
        └── osicat
            ├── posix
            │   ├── basic-unix.fasl
            │   ├── basic-unixint.fasl
            │   ├── early.fasl
            │   ├── libosicat.so
            │   ├── linux.fasl
            │   ├── misc.fasl
            │   ├── packages.fasl
            │   ├── unix.fasl
            │   ├── unixint.fasl
            │   └── wrappers.fasl
            ├── src
            │   ├── fd-streams.fasl
            │   ├── osicat.fasl
...
--8<---------------cut here---------------end--------------->8---

I get the following error:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix environment --ad-hoc sbcl sbcl-osicat -- \
    sbcl --no-userinit --eval '(require :asdf)' \
         --eval '(asdf:load-system "osicat")'

...
ASDF could not load osicat because Error opening
#P"/gnu/store/...-sbcl-osicat-0.7.0-1.de0c18a/lib/common-lisp/sbcl/osicat/posix/basic-unixint__grovel.c":
Read-only file system.

debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD "main
thread" RUNNING {10009F80D3}>: Error opening
#P"/gnu/store/...-sbcl-osicat-0.7.0-1.de0c18a/lib/common-lisp/sbcl/osicat/posix/basic-unixint__grovel.c":
Read-only file system
...
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]


Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Guillaume Le Vaillant <glv@posteo.net> writes:
>
>> I thought about having the sources, SBCL compiled files and ECL compiled
>> files respectively in the 'out', 'sbcl' and 'ecl' packages outputs;
>> however I thought there could be issues in some cases.
>>
>> For example, if a profile contained cl-xyz and cl-xyz:sbcl, and if the
>> user tried to load this xyz system in ECL, then I think ECL would try
>> to compile the system and write the compiled files to cl-xyz:sbcl and
>> fail because it is read-only. That's because cl-xyz:sbcl contains the
>> ASDF configuration indicating "the compiled files for cl-xyz are in
>> cl-xyz:sbcl", and ECL is going to read that configuration.
>>
>> It might be possible to have smarter ASDF configuration files behaving
>> differently depending on the lisp implementation running, but I have not
>> investigated this for the moment.
>
> There is probably a way to tell where to load the libraries from, and
> where to compile them.
>
> By default, each compiler compiles to
> ~/.cache/common-lisp/$compiler_name-$compiler_version.
>
> This is what ECL should do here.  The ASDF configuration should be so
> that it does not change this  behaviour.

The ':implementation-type' or ':function' keywords of ASDF
configuration files described in [1] and [2] could be useful to do that.

Now, let's suppose that we put the sources in cl-xyz, the SBCL
pre-compiled files in cl-xyz:sbcl and the ECL pre-compiled files in
cl-xyz:ecl.
If a user installs only cl-xyz (the sources) and loads the system using
SBCL or ECL, I think he would expect the lisp implementation to compile
the thing and store the compiled files in the default
'$HOME/.cache/common-lisp/...' location, because he didn't install the
pre-compiled files.
So we would need the ASDF output-translation configuration to be able to
say something like: "if the pre-compiled files for the running lisp
implementation exist in '/gnu/store/...' and if the Guix package for
these pre-compiled files is installed in the current profile or
environment, then use them, else use the default
$HOME/.cache/common-lisp/...' directory".

I guess cl-xyz:sbcl and cl-xyz:ecl would also need to have links to the
ASDF configuration and to the sources in cl-xyz, in case the user
installs only cl-xyz:sbcl or only cl-xyz:ecl.

[1] https://common-lisp.net/project/asdf/asdf/Configuration-DSL.html
[2] https://common-lisp.net/project/asdf/asdf/Output-Configuration-DSL.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

Guillaume Le Vaillant <glv@posteo.net> writes:

> The ':implementation-type' or ':function' keywords of ASDF
> configuration files described in [1] and [2] could be useful to do that.
>
> Now, let's suppose that we put the sources in cl-xyz, the SBCL
> pre-compiled files in cl-xyz:sbcl and the ECL pre-compiled files in
> cl-xyz:ecl.
> If a user installs only cl-xyz (the sources) and loads the system using
> SBCL or ECL, I think he would expect the lisp implementation to compile
> the thing and store the compiled files in the default
> '$HOME/.cache/common-lisp/...' location, because he didn't install the
> pre-compiled files.
> So we would need the ASDF output-translation configuration to be able to
> say something like: "if the pre-compiled files for the running lisp
> implementation exist in '/gnu/store/...' and if the Guix package for
> these pre-compiled files is installed in the current profile or
> environment, then use them, else use the default
> $HOME/.cache/common-lisp/...' directory".
>
> I guess cl-xyz:sbcl and cl-xyz:ecl would also need to have links to the
> ASDF configuration and to the sources in cl-xyz, in case the user
> installs only cl-xyz:sbcl or only cl-xyz:ecl.

Agreed on all points!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]


I was thinking about what the package definitions would look like if we
put pre-compiled files in package outputs instead of in their own
packages. For example with a cl-xyz package having cl-abc as native
input and cl-def as input:

 - cl-xyz package needs to propagate cl-abc and cl-def (sources).
 - cl-xyz:sbcl has cl-abc:sbcl as native input and cl-def:sbcl as input.
 - cl-xyz:ecl has cl-abc:ecl as native input and cl-def:ecl as input.


So the package definition would look like:

--8<---------------cut here---------------start------------->8---
(package
  ...
  (native-inputs
   `(("cl-abc-sbcl" ,cl-abc "sbcl")
     ("cl-abc-ecl" ,cl-abc "ecl")))
  (inputs
   `(("cl-def-sbcl" ,cl-def "sbcl")
     ("cl-def-ecl" ,cl-def "ecl")))
  (propagated-inputs
   `(("cl-abc" ,cl-abc)
     ("cl-def" ,cl-def)))
  ...
  )
--8<---------------cut here---------------end--------------->8---


It's a bit burdensome to write, but we could have a define-lisp-package
macro taking a lighter package definition and transforming it a full
package definition as above:

--8<---------------cut here---------------start------------->8---
(define-lisp-package cl-xyz
  (package
    ...
    (native-inputs
     `(("cl-abc" ,cl-abc)))
    (inputs
     `(("cl-def" ,cl-def)))
    ...
    ))
--8<---------------cut here---------------end--------------->8---


However, it would mean that installing only cl-xyz:sbcl would download
the sbcl pre-compiled files and the ecl pre-compiled files for all the
dependencies of cl-xyz (direct and transitive).
The only way to prevent downloading all these unnecessary ecl
pre-compiled files would be for the package definition to have a way to
say "the sbcl outputs only depend on the sources and the sbcl outputs of
the dependencies", but I don't think that's possible...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

This may very well be the reason why the ECL / SBCL packages are defined
separately in the previous build system...

Any idea, anyone?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]


To further simplify package definitions, I thought we could remove the
need for the 'asd-files' keyword in the package's arguments by just
reading all the '.asd' files in the directory tree of the sources.

Can you think of a case where this would cause an issue?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Some .asd definitions have dependencies (declared with
:system-depends-on).
A common dependency is prove-asdf.

If we read all .asd then we must drag all ASDF dependencies.  This can be a
burden, say, for a test system that is not supported in Guix at the moment.

My intuition is that parsing all ASD files is a good default behaviour
but we should allow to override it with the asd-files keyword.

Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Some .asd definitions have dependencies (declared with
> :system-depends-on).
> A common dependency is prove-asdf.
>
> If we read all .asd then we must drag all ASDF dependencies.  This can be a
> burden, say, for a test system that is not supported in Guix at the moment.
>
> My intuition is that parsing all ASD files is a good default behaviour
> but we should allow to override it with the asd-files keyword.

Sounds good to me.  When asd-files is provided we respect it, otherwise
we’ll try to use them all.

-- 
Ricardo

Re: Improve ASDF build system for Common Lisp libraries

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> writes:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Some .asd definitions have dependencies (declared with
>> :system-depends-on).
>> A common dependency is prove-asdf.
>>
>> If we read all .asd then we must drag all ASDF dependencies.  This can be a
>> burden, say, for a test system that is not supported in Guix at the moment.
>>
>> My intuition is that parsing all ASD files is a good default behaviour
>> but we should allow to override it with the asd-files keyword.
>
> Sounds good to me.  When asd-files is provided we respect it, otherwise
> we’ll try to use them all.

+1 to allowing overrides for =asd-files=. If nothing else, packages need
to be flexible!

In addition to what Pierre is pointing out, the only issue I can think
of with reading in all asd files is perhaps source trees which vendor
packages. I don't think this is common in Common Lisp source trees, so
maybe that's something we can deal with if it comes up.

-- 
Katherine

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]


Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>>
>>> Some .asd definitions have dependencies (declared with
>>> :system-depends-on).
>>> A common dependency is prove-asdf.
>>>
>>> If we read all .asd then we must drag all ASDF dependencies.  This can be a
>>> burden, say, for a test system that is not supported in Guix at the moment.
>>>
>>> My intuition is that parsing all ASD files is a good default behaviour
>>> but we should allow to override it with the asd-files keyword.
>>
>> Sounds good to me.  When asd-files is provided we respect it, otherwise
>> we’ll try to use them all.
>
> +1 to allowing overrides for =asd-files=. If nothing else, packages need
> to be flexible!
>
> In addition to what Pierre is pointing out, the only issue I can think
> of with reading in all asd files is perhaps source trees which vendor
> packages. I don't think this is common in Common Lisp source trees, so
> maybe that's something we can deal with if it comes up.

Indeed there are a few packages that fail to build as-is when reading
all the asd files (example asd file somewhere in the directory tree or
things like that); 'asd-files' is useful in those case.

I pushed the code for the new behavior to the wip-lisp branch (commit
952fafb2a3c7a0978cc6a96268ad0632558b212d and following).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

I'll test next week, but if anyone else can test Guillaume's work before
that (e.g. by building StumpWM and Nyxt -- with sbcl inputs), feel free
to merge.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 5772 bytes --]

I've retested wip-lisp on 851abcf6c9c15d90cb77caaaa57b40d10c3b4835,
everything seems to work!

Nit: Maybe enable tests in ecl-numcl ?

I've successfully tested Nyxt with the following recipe:

--8<---------------cut here---------------start------------->8---
(define-public nyxt
  (package
    (name "nyxt")
    ;; Package the pre-release because latest stable 1.5.0 does not build
    ;; anymore.
    (version "2-pre-release-1")
    (source
     (origin
       (method git-fetch)
       (uri (git-reference
             ;; TODO: Mirror seems to hang, let's fallback to GitHub for now.
             ;; (url "https://source.atlas.engineer/public/nyxt")
             (url "https://github.com/atlas-engineer/nyxt")
             (commit version)))
       (sha256
        (base32
         "0aipsmzqnlkmy001cihz2jnc0hja8c10rm08jycxr05j3gx3qsxd"))
       (file-name (git-file-name "nyxt" version))))
    (build-system gnu-build-system)
    (arguments
     `(#:make-flags (list "nyxt" "NYXT_INTERNAL_QUICKLISP=false"
                          (string-append "DESTDIR=" (assoc-ref %outputs "out"))
                          "PREFIX=")
       #:strip-binaries? #f             ; Stripping breaks SBCL binaries.
       #:phases
       (modify-phases %standard-phases
         (add-after 'unpack 'patch-version ; Version is guessed from .git which Guix does not have.
           (lambda* (#:key inputs #:allow-other-keys)
             (let ((version (format #f "~a" ,version))
                   (file "source/global.lisp"))
               (chmod file #o666)
               (let ((port (open-file file "a")))
                 (format port "(setf +version+ ~s)" version)
                 (close-port port)))
             #t))
         (add-before 'build 'make-desktop-version-number
           (lambda _
             (with-output-to-file "version"
               (lambda _
                 (format #t "~a" ,version)
                 #t))))

         (delete 'configure)
         (add-before 'build 'fix-common-lisp-cache-folder
           (lambda _
             (setenv "HOME" "/tmp")
             #t))
         (add-after 'install 'wrap-program
           (lambda* (#:key inputs outputs #:allow-other-keys)
             (let* ((bin (string-append (assoc-ref outputs "out") "/bin/nyxt"))
                    (glib-networking (assoc-ref inputs "glib-networking"))
                    (libs '("gsettings-desktop-schemas"))
                    (path (string-join
                           (map (lambda (lib)
                                  (string-append (assoc-ref inputs lib) "/lib"))
                                libs)
                           ":"))
                    (gi-path (string-join
                              (map (lambda (lib)
                                     (string-append (assoc-ref inputs lib) "/lib/girepository-1.0"))
                                   libs)
                              ":"))
                    (xdg-path (string-join
                               (map (lambda (lib)
                                      (string-append (assoc-ref inputs lib) "/share"))
                                    libs)
                               ":")))
               (wrap-program bin
                 `("GIO_EXTRA_MODULES" prefix
                   (,(string-append glib-networking "/lib/gio/modules")))
                 `("GI_TYPELIB_PATH" prefix (,gi-path))
                 `("LD_LIBRARY_PATH" ":" prefix (,path))
                 `("XDG_DATA_DIRS" ":" prefix (,xdg-path)))
               #t))))))
    (native-inputs
     `(("prove" ,sbcl-prove)
       ("sbcl" ,sbcl)))
    (inputs
     `(("alexandria" ,sbcl-alexandria)
       ("bordeaux-threads" ,sbcl-bordeaux-threads)
       ("sbcl-containers" ,sbcl-cl-containers)
       ("sbcl-css" ,sbcl-cl-css)
       ("sbcl-json" ,sbcl-cl-json)
       ("sbcl-markup" ,sbcl-cl-markup)
       ("sbcl-ppcre" ,sbcl-cl-ppcre)
       ("sbcl-prevalence" ,sbcl-cl-prevalence)
       ("closer-mop" ,sbcl-closer-mop)
       ("cluffer" ,sbcl-cluffer)
       ("dexador" ,sbcl-dexador)
       ("enchant" ,sbcl-enchant)
       ("fset" ,sbcl-fset)
       ("iolib" ,sbcl-iolib)
       ("local-time" ,sbcl-local-time)
       ("log4cl" ,sbcl-log4cl)
       ("lparallel" ,sbcl-lparallel)
       ("mk-string-metrics" ,sbcl-mk-string-metrics)
       ("moptilities" ,sbcl-moptilities)
       ("osicat" ,sbcl-osicat)
       ("parenscript" ,sbcl-parenscript)
       ("plump" ,sbcl-plump)
       ("quri" ,sbcl-quri)
       ("serapeum" ,sbcl-serapeum)
       ("str" ,sbcl-cl-str)
       ("swank" ,sbcl-slime-swank)
       ("trivia" ,sbcl-trivia)
       ("trivial-clipboard" ,sbcl-trivial-clipboard)
       ("trivial-features" ,sbcl-trivial-features)
       ("trivial-package-local-nicknames" ,sbcl-trivial-package-local-nicknames)
       ("trivial-types" ,sbcl-trivial-types)
       ("unix-opts" ,sbcl-unix-opts)
       ;; WebKitGTK deps
       ("sbcl-cffi-gtk" ,sbcl-cl-cffi-gtk)
       ("sbcl-webkit" ,sbcl-cl-webkit)
       ("glib-networking" ,glib-networking)
       ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)))
    (synopsis "Extensible web-browser in Common Lisp")
    (home-page "https://nyxt.atlas.engineer")
    (description "Nyxt is a keyboard-oriented, extensible web-browser
designed for power users.  The application has familiar Emacs and VI
key-bindings and is fully configurable and extensible in Common Lisp.")
    (license license:bsd-3)))
--8<---------------cut here---------------end--------------->8---


I haven't tested StumpWM, can anyone do it?
If StumpWM passes, feel free to merge this patchset.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]


Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> I've retested wip-lisp on 851abcf6c9c15d90cb77caaaa57b40d10c3b4835,
> everything seems to work!

Thanks for testing.


> Nit: Maybe enable tests in ecl-numcl ?

Done.


> I've successfully tested Nyxt with the following recipe:
>
> --8<---------------cut here---------------start------------->8---
> (define-public nyxt
> ...
> --8<---------------cut here---------------end--------------->8---

I pushed your recipe for Nyxt in wip-lisp. Thanks.


> I haven't tested StumpWM, can anyone do it?
> If StumpWM passes, feel free to merge this patchset.

I just tested StumpWM's basic functionalities (key bindings, modeline)
and I didn't see any issue.

So unless there is a last minute blocker, I'm going to merge wip-lisp
into staging (given that it should rebuild between 900 and 1000
packages).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Improve ASDF build system for Common Lisp libraries

[Ricardo Wurmus]

Guillaume Le Vaillant <glv@posteo.net> writes:

> So unless there is a last minute blocker, I'm going to merge wip-lisp
> into staging (given that it should rebuild between 900 and 1000
> packages).

Sounds good to me.  Thanks for working on this!

-- 
Ricardo

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

In the past changes to the Lisp build system were directly pushed on
master.

The complete collection of Lisp packages is built within minutes by
Cuirass (I think only ironclad takes more than a minute to build).

Besides, only uglify-js has dependents (99 of them).

This time the changes are quite dramatic for the Lisp system, so
staging might be the safest option.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]