search

rabbibotton / clog

CLOG - The Common Lisp Omnificent GUI
Other
1.48k stars 101 forks source link

Some systems failed to build for Quicklisp dist #235

Closed quicklisp closed 1 year ago

quicklisp commented 1 year ago

Building with SBCL 2.2.7.28-02bc916fd / ASDF 3.3.5 for quicklisp dist creation.

Trying to build commit id fa23c4d881c0e83b9f0784ae85d4629ac2e879b4

clog/tools fails to build with the following error:

; caught ERROR:
;   READ error during COMPILE-FILE: Package QUICKLISP-CLIENT does not exist. Line: 143, Column: -1, File-Position: 10118 Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/quicklisp/quicklisp-controller/dist/build-cache/clog/c82573d0917c14205abb276c78fe0878235824d8/clog-20220925-git/tools/systems.lisp" {102CB80363}>
...
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016D0003}>: COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "clog/tools" "systems">

Full log here

quicklisp commented 1 year ago

For context, quicklisp is not part of the quicklisp dist build process. Projects should not use quicklisp client functions in general.

rabbibotton commented 1 year ago

As the CLOG IDE uses quicklisp as fairly integral part of the project system is there a reason for this policy? Is there a way to change it if there is not a reason?

rabbibotton commented 1 year ago

If I need to remove how much time is there to next release, my holidays start for next few days soon?

quicklisp commented 1 year ago

The original reason was to discourage embedding of "(ql:quickload ...)" in sources, and to encourage the creation of proper dependencies in system definitions. And it's also to discourage the assumption that quicklisp is everywhere, which makes libraries less portable, as not everyone uses or wants to use Quicklisp.

I recognize it's a different situation when the library or application is explicitly related to working with Quicklisp and quicklisp systems. In that case, it's a technical limitation on my side that Quicklisp isn't loaded and can't be referenced during the dist build process.

Other projects have worked around this by deferring Quicklisp symbol lookup, via something like (funcall (read-from-string "ql:quickload") ...) or similar.

I don't have a short-term fix for including Quicklisp in the dist build environment, but it's on my todo list.

On Sun, Sep 25, 2022 at 12:53 PM David Botton @.***> wrote:

If I need to remove how much time is there to next release, my holidays start for next few days soon?

— Reply to this email directly, view it on GitHub https://github.com/rabbibotton/clog/issues/235#issuecomment-1257233427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPNLO5D4MHDAA5I43X6PLWAB7Q3ANCNFSM6AAAAAAQVEYCMA . You are receiving this because you authored the thread.Message ID: @.***>

rabbibotton commented 1 year ago

Provided I have power (hurricane already making issues) I'll get a fix in tomorrow God willing

On Mon, Sep 26, 2022, 8:31 AM Zach Beane @.***> wrote:

The original reason was to discourage embedding of "(ql:quickload ...)" in sources, and to encourage the creation of proper dependencies in system definitions. And it's also to discourage the assumption that quicklisp is everywhere, which makes libraries less portable, as not everyone uses or wants to use Quicklisp.

I recognize it's a different situation when the library or application is explicitly related to working with Quicklisp and quicklisp systems. In that case, it's a technical limitation on my side that Quicklisp isn't loaded and can't be referenced during the dist build process.

Other projects have worked around this by deferring Quicklisp symbol lookup, via something like (funcall (read-from-string "ql:quickload") ...) or similar.

I don't have a short-term fix for including Quicklisp in the dist build environment, but it's on my todo list.

On Sun, Sep 25, 2022 at 12:53 PM David Botton @.***> wrote:

If I need to remove how much time is there to next release, my holidays start for next few days soon?

— Reply to this email directly, view it on GitHub <https://github.com/rabbibotton/clog/issues/235#issuecomment-1257233427 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLO5D4MHDAA5I43X6PLWAB7Q3ANCNFSM6AAAAAAQVEYCMA

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/rabbibotton/clog/issues/235#issuecomment-1257964158, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYUEFMVLNGF6RW7NSNFXOLWAGJTLANCNFSM6AAAAAAQVEYCMA . You are receiving this because you commented.Message ID: @.***>

rabbibotton commented 1 year ago

done, thanks!

On Tue, Sep 27, 2022 at 8:25 PM David Botton @.***> wrote:

Provided I have power (hurricane already making issues) I'll get a fix in tomorrow God willing

On Mon, Sep 26, 2022, 8:31 AM Zach Beane @.***> wrote:

The original reason was to discourage embedding of "(ql:quickload ...)" in sources, and to encourage the creation of proper dependencies in system definitions. And it's also to discourage the assumption that quicklisp is everywhere, which makes libraries less portable, as not everyone uses or wants to use Quicklisp.

I recognize it's a different situation when the library or application is explicitly related to working with Quicklisp and quicklisp systems. In that case, it's a technical limitation on my side that Quicklisp isn't loaded and can't be referenced during the dist build process.

Other projects have worked around this by deferring Quicklisp symbol lookup, via something like (funcall (read-from-string "ql:quickload") ...) or similar.

I don't have a short-term fix for including Quicklisp in the dist build environment, but it's on my todo list.

On Sun, Sep 25, 2022 at 12:53 PM David Botton @.***> wrote:

If I need to remove how much time is there to next release, my holidays start for next few days soon?

— Reply to this email directly, view it on GitHub <https://github.com/rabbibotton/clog/issues/235#issuecomment-1257233427 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AACPNLO5D4MHDAA5I43X6PLWAB7Q3ANCNFSM6AAAAAAQVEYCMA

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/rabbibotton/clog/issues/235#issuecomment-1257964158, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYUEFMVLNGF6RW7NSNFXOLWAGJTLANCNFSM6AAAAAAQVEYCMA . You are receiving this because you commented.Message ID: @.***>