unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Improve ASDF build system for Common Lisp libraries
@ 2020-09-12  9:36 Guillaume Le Vaillant
  2020-09-12 10:26 ` Pierre Neidhardt
                   ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-12  9:36 UTC (permalink / raw)
  To: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12  9:36 Improve ASDF build system for Common Lisp libraries Guillaume Le Vaillant
@ 2020-09-12 10:26 ` Pierre Neidhardt
  2020-09-12 11:11   ` Pierre Neidhardt
  2020-09-12 15:35 ` Katherine Cox-Buday
  2020-09-12 18:59 ` Konrad Hinsen
  2 siblings, 1 reply; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-12 10:26 UTC (permalink / raw)
  To: Guillaume Le Vaillant, guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12 10:26 ` Pierre Neidhardt
@ 2020-09-12 11:11   ` Pierre Neidhardt
  2020-09-12 12:06     ` Guillaume Le Vaillant
  2020-09-12 12:07     ` Pierre Neidhardt
  0 siblings, 2 replies; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-12 11:11 UTC (permalink / raw)
  To: Guillaume Le Vaillant, guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12 11:11   ` Pierre Neidhardt
@ 2020-09-12 12:06     ` Guillaume Le Vaillant
  2020-09-13 10:08       ` Guillaume Le Vaillant
  2020-09-13 10:36       ` Pierre Neidhardt
  2020-09-12 12:07     ` Pierre Neidhardt
  1 sibling, 2 replies; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-12 12:06 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12 11:11   ` Pierre Neidhardt
  2020-09-12 12:06     ` Guillaume Le Vaillant
@ 2020-09-12 12:07     ` Pierre Neidhardt
  2020-09-15 10:00       ` Guillaume Le Vaillant
  1 sibling, 1 reply; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-12 12:07 UTC (permalink / raw)
  To: Guillaume Le Vaillant, guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12  9:36 Improve ASDF build system for Common Lisp libraries Guillaume Le Vaillant
  2020-09-12 10:26 ` Pierre Neidhardt
@ 2020-09-12 15:35 ` Katherine Cox-Buday
  2020-09-12 18:59 ` Konrad Hinsen
  2 siblings, 0 replies; 21+ messages in thread
From: Katherine Cox-Buday @ 2020-09-12 15:35 UTC (permalink / raw)
  To: Guillaume Le Vaillant; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12  9:36 Improve ASDF build system for Common Lisp libraries Guillaume Le Vaillant
  2020-09-12 10:26 ` Pierre Neidhardt
  2020-09-12 15:35 ` Katherine Cox-Buday
@ 2020-09-12 18:59 ` Konrad Hinsen
  2 siblings, 0 replies; 21+ messages in thread
From: Konrad Hinsen @ 2020-09-12 18:59 UTC (permalink / raw)
  To: Guillaume Le Vaillant, guix-devel

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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12 12:06     ` Guillaume Le Vaillant
@ 2020-09-13 10:08       ` Guillaume Le Vaillant
  2020-09-13 10:31         ` Pierre Neidhardt
  2020-09-13 10:36       ` Pierre Neidhardt
  1 sibling, 1 reply; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-13 10:08 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-13 10:08       ` Guillaume Le Vaillant
@ 2020-09-13 10:31         ` Pierre Neidhardt
  2020-09-13 11:56           ` Guillaume Le Vaillant
  0 siblings, 1 reply; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-13 10:31 UTC (permalink / raw)
  To: Guillaume Le Vaillant; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12 12:06     ` Guillaume Le Vaillant
  2020-09-13 10:08       ` Guillaume Le Vaillant
@ 2020-09-13 10:36       ` Pierre Neidhardt
  2020-09-13 12:49         ` Guillaume Le Vaillant
  1 sibling, 1 reply; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-13 10:36 UTC (permalink / raw)
  To: Guillaume Le Vaillant; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-13 10:31         ` Pierre Neidhardt
@ 2020-09-13 11:56           ` Guillaume Le Vaillant
  0 siblings, 0 replies; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-13 11:56 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-13 10:36       ` Pierre Neidhardt
@ 2020-09-13 12:49         ` Guillaume Le Vaillant
  2020-09-13 13:15           ` Pierre Neidhardt
  0 siblings, 1 reply; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-13 12:49 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-13 12:49         ` Guillaume Le Vaillant
@ 2020-09-13 13:15           ` Pierre Neidhardt
  2020-09-14 13:39             ` Guillaume Le Vaillant
  0 siblings, 1 reply; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-13 13:15 UTC (permalink / raw)
  To: Guillaume Le Vaillant; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-13 13:15           ` Pierre Neidhardt
@ 2020-09-14 13:39             ` Guillaume Le Vaillant
  2020-09-15  6:18               ` Pierre Neidhardt
  0 siblings, 1 reply; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-14 13:39 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-14 13:39             ` Guillaume Le Vaillant
@ 2020-09-15  6:18               ` Pierre Neidhardt
  0 siblings, 0 replies; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-15  6:18 UTC (permalink / raw)
  To: Guillaume Le Vaillant; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-12 12:07     ` Pierre Neidhardt
@ 2020-09-15 10:00       ` Guillaume Le Vaillant
  2020-09-15 10:54         ` Pierre Neidhardt
  0 siblings, 1 reply; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-15 10:00 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel, Katherine Cox-Buday

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-15 10:00       ` Guillaume Le Vaillant
@ 2020-09-15 10:54         ` Pierre Neidhardt
  2020-09-15 11:07           ` Ricardo Wurmus
  0 siblings, 1 reply; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-15 10:54 UTC (permalink / raw)
  To: Guillaume Le Vaillant; +Cc: guix-devel, Katherine Cox-Buday

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-15 10:54         ` Pierre Neidhardt
@ 2020-09-15 11:07           ` Ricardo Wurmus
  2020-09-15 14:12             ` Katherine Cox-Buday
  0 siblings, 1 reply; 21+ messages in thread
From: Ricardo Wurmus @ 2020-09-15 11:07 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel, Katherine Cox-Buday


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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-15 11:07           ` Ricardo Wurmus
@ 2020-09-15 14:12             ` Katherine Cox-Buday
  2020-09-15 16:28               ` Guillaume Le Vaillant
  0 siblings, 1 reply; 21+ messages in thread
From: Katherine Cox-Buday @ 2020-09-15 14:12 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-15 14:12             ` Katherine Cox-Buday
@ 2020-09-15 16:28               ` Guillaume Le Vaillant
  2020-09-17  9:45                 ` Pierre Neidhardt
  0 siblings, 1 reply; 21+ messages in thread
From: Guillaume Le Vaillant @ 2020-09-15 16:28 UTC (permalink / raw)
  To: Katherine Cox-Buday; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Improve ASDF build system for Common Lisp libraries
  2020-09-15 16:28               ` Guillaume Le Vaillant
@ 2020-09-17  9:45                 ` Pierre Neidhardt
  0 siblings, 0 replies; 21+ messages in thread
From: Pierre Neidhardt @ 2020-09-17  9:45 UTC (permalink / raw)
  To: Guillaume Le Vaillant, Katherine Cox-Buday; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2020-09-17  9:48 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-12  9:36 Improve ASDF build system for Common Lisp libraries Guillaume Le Vaillant
2020-09-12 10:26 ` Pierre Neidhardt
2020-09-12 11:11   ` Pierre Neidhardt
2020-09-12 12:06     ` Guillaume Le Vaillant
2020-09-13 10:08       ` Guillaume Le Vaillant
2020-09-13 10:31         ` Pierre Neidhardt
2020-09-13 11:56           ` Guillaume Le Vaillant
2020-09-13 10:36       ` Pierre Neidhardt
2020-09-13 12:49         ` Guillaume Le Vaillant
2020-09-13 13:15           ` Pierre Neidhardt
2020-09-14 13:39             ` Guillaume Le Vaillant
2020-09-15  6:18               ` Pierre Neidhardt
2020-09-12 12:07     ` Pierre Neidhardt
2020-09-15 10:00       ` Guillaume Le Vaillant
2020-09-15 10:54         ` Pierre Neidhardt
2020-09-15 11:07           ` Ricardo Wurmus
2020-09-15 14:12             ` Katherine Cox-Buday
2020-09-15 16:28               ` Guillaume Le Vaillant
2020-09-17  9:45                 ` Pierre Neidhardt
2020-09-12 15:35 ` Katherine Cox-Buday
2020-09-12 18:59 ` Konrad Hinsen

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git