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 <rcar...@pinyon.org
<mailto:rcar...@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
