asdf-devel

Download

asdf-devel@common-lisp.net

December 2025

1 participants
2 discussions

Balancing ASDF Configuration for Precompiled OS and User-Compiled FASL Files
by Joseph Mingrone 01 Dec '25

01 Dec '25

Hello, I'm attempting to adjust the ASDF configuration for FreeBSD CL ports/packages to balance the use of precompiled FASL files from OS packages with the ability to compile and write code under users' home directories. Details are below. Any advice would be appreciated. The system-wide configuration [0] I'm attempting to adjust is used both when building FreeBSD CL OS packages and on target systems. Specifically, it: - sets up a central registry, - enforces a filesystem layout, - and configures output translations. With this configuration, users can run `pkg install cl-alexandria-sbcl` and two packages will be installed: - cl-alexandria, essentially the upstream repository, - cl-alexandria-sbcl, the compiled code. From their Lisp implementation, users only need to execute (asdf:load-system :alexandria) and no local compilation is required. However, if a user installs only cl-alexandria without cl-alexandria-sbcl, issues arise. Due to the output translations, ASDF attempts to write compiled code to a location where the user lacks write access. On the other hand, if we remove the output translations on target systems, all FASL files provided by the OS packages are ignored, and ASDF tries to recompile and write them under ~/.cache/common-lisp/. Is there a way to configure ASDF to recognize and accept the FASL files from the OS packages and compile and write any missing FASL files to the default untranslated location under ~/.cache/common-lisp/? Thank you, Joe [0] https://cgit.freebsd.org/ports/tree/devel/cl-asdf/bsd.cl-asdf.mk

3 8

Fwd: Naive DEFSYSTEM replacement
by Faré 01 Dec '25

01 Dec '25

I thought I would forward this message I sent to Lisp-HUG (the LispWorks users mailing-list), which is about ASDF. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a mature society, “civil servant” is semantically equal to “civil *master*”. — Robert Heinlein, “Time Enough For Love” ---------- Forwarded message --------- From: Faré <fahree(a)gmail.com> Date: Sun, Nov 30, 2025 at 11:38 PM Subject: Re: Naive DEFSYSTEM replacement To: Adam Weaver <adam(a)cleversure.com.au> Cc: lisp-hug(a)lispworks.com <lisp-hug(a)lispworks.com> Sorry to only reply months later---I don't actively follow the lisp-hug mailing list. On Sun, Jul 27, 2025 at 7:24 PM Adam Weaver (as adam at cleversure dot com dot au) <lisp-hug(a)lispworks.com> wrote: > Obviously *no-one* really knows (nowadays) why ASDF is > as complicated in its implementation as it is. > 1. Having written, rewritten or carefully reviewed each and every line of code in ASDF 3.3.4, I do know what each and every line of it is about. Robert Goldman has been maintaining it since I left the CL community (thank you so much, Robert), but his commits are clean and easy enough to follow, and I am confident I can grok the diffs if needed---and happily or unhappily, it's not that much diffs. While I'm not active in CL anymore, my knowledge of ASDF is still available to Robert and any developer or user of ASDF when needed. 2. ASDF is actually not complicated at all. COMPARED TO WHAT??? The equivalent in the C universe would be a mix of libc (portability layer), make (building files), ld.so (recursive dynamic loader), autoconf (features detection), pkg-config (library path detection), ld (static linker---ASDF can create standalone binaries). If you count the lines of code in all these pieces of blub, even if you strip the parts that ASDF doesn't cover (because you don't need them to build, or at least not when you have CL), you'll get something more than 10x larger than ASDF. 3. ASDF can build software *and incrementally update it*, in-image, portably, across tens of implementations including some you've never heard of on operating systems you don't suspect exist. And then, ASDF is itself extensible, from within ASDF; and unlike any other build software in any other language bar none, it handles extensions to the build system from within the build system, through arbitrary many layers of extensions-loading-extensions, in the same session. 4. Every line is necessary, though I admit there are a couple of UIOP functions I added only so UIOP could claim 100% functionality coverage as a replacement for CL-FAD. Even the NEST macro is necessary, seeing how it interacts with #+ in launch-program and such, though ASDF doesn't reach the 19-level deep that my LIL code reaches (and so NEST belies the joke about the end of an AI written in Lisp). I challenge you or anyone to show me a function you think has unclear or unnecessary purpose---the internals are well commented and the exported functions are well documented. 5. More than half of ASDF is actually the portability layer UIOP. I broke up the source code into many files for ASDF 3, and since then it is well organized in a logical way that is relatively easy to follow if you read the files in the dependency order declared in the .asd files. While the documentation could always be improved, I have no doubt that any serious would-be maintainer could read the documentation (for the concepts) then the source code (for their implementation) and come to understand ASDF in a matter of days, though it might still take weeks or months to really grok how the system just all fits together. The subtlest bit I believe would be CRDT underlying action-status (in plan.lisp); yet considering all the functionality it affords I still wouldn't call it "complicated". PS: I am currently looking for permanent or temporary work, and would gladly take a contract that involves CL. Regards, —♯ƒ • François-René Rideau • Chief Scientist, MuKn.com/fare “A slave is one who waits for someone else to free him.” — Ezra Pound

1 0