Bingo! Thank you very much. I regret that I hadn't thought to try that, it's obvious in hindsight. I was led astray I think by fare's very concise wording in the UIOP manual 2 UIOP/Package uiop.pdf page2: [...] cl:defpackage. use -- as per cl:defpackage, but if neither use, use-reexport, mix, nor mix-reexport is supplied, then it is equivalent to specifying (:use :common- lisp). This is unlike cl:defpackage for which the behavior of a form without use is implementation-dependent. recycle -- Recycle the package’s exported symbols [...] Anyway I thank you all for your patience, and boy do I look forward to making some progress in shoving C++ onto the ash-heap of (my) history and moving forward into sanity. All the best, Russell On 1/8/25 7:05 PM, Alexander Fedorov wrote:
Hello!
IIUC, the problem here is not with ASDF but with the package definition (I could be wrong about the reason because I can't really test it in the exact same setup at the moment). Specifically, when defining a package, if there is no :use clause, an implementation-dependent default is used, which almost always includes the "CL" ("COMMON-LISP") package. However, when you are specifying (:use :alexandria), the default is no longer used, and thus the "CL" package is not being used. Thus DEFUN no longer refers to the macro CL:DEFUN, but to the symbol HELLO/SRC/MAIN::DEFUN, which has no function or macro associated. And so the function definition is instead treated as a function call, and while evaluating the first "argument", it signals an error that the variable MAIN is unbound (doesn't exist).
Dunno what exactly can go right or wrong when debugging an issue like that, but IIRC errors that happen during the compiling/loading of a system seem to be harder to read/notice than usual because by default they are intercepted and reported by ASDF, which afterwards signals a more generic error. You could probably check the ASDF:*COMPILE-FILE- FAILURE-BEHAVIOUR* variable for controlling that (shortly describes in the manual, section 10.2).
Best regards, Alexander Fedorov.
On Thu, Jan 9, 2025, 00:37 Russell L. Carter <rcarter@pinyon.org <mailto:rcarter@pinyon.org>> wrote:
Greetings,
I am a common-lisp noob. I am not a programmer noob, nor a build system noob.
I have carefully studied fare's asdf manual, pages 25-26 in the pdf and backwards through the reverse dependencies of the terms used, about the package-inferred-system. I have a problem that I've whittled down to a very small snippet.
I'm using SBCL 2.4.10.117-507e7ae05 and its native ASDF, but also tested against ASDF repo head (ln -s into ~/common-lisp, verified in the repl).
My question is why this system, located in file "./hello.asd", containing:
***************************************************************** (asdf:defsystem "hello" :class :package-inferred-system :depends-on ("hello/src/main")) *****************************************************************
paired with the system/package file "./src/main.lisp", containing:
****************************************************************** (uiop:define-package :hello/src/main ;; (:use :alexandria) ;; XXXRLC This line fails: "The variable MAIN ;; is unbound". I have no idea why. Backtrace provides no clues ;; (to me). Load the library in the repl matters not. Elide that ;; line and (asdf:load-system "hello") => T and then CL-USER> ;; (hello/src/main:main) => urg \n "urg" as expected. (:export #:main))
(in-package :hello/src/main) (defun main () (write-line "urg")) *******************************************************************
fails as described in the comment. Sure I would like the answer but the more interesting question is how could I debug this failure?
I slogged through the late '90s debugging complex C++ template programming errors. Pages and pages of output. I don't mind doing it again. But I don't know where to start with this ASDF build system.
Thank you for any suggestions, obviously the answer must be trivial.
All the best, Russell L. Carter