Compile and Build utility.mime

[monkpearman]

I'm running into similar problems getting de.setf.utility to compile sbcl-2.4.6-macosx-arm64 w/ asdf 3.3.1
hangs on the package definition for mime.

cl-user> (asdf:load-system :de.setf.utility.mime)
=>
failed AVER: (EQ POP (CAR END-STACK))
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at http://sbcl.sourceforge.net/.
[Condition of type SB-INT:BUG]

Restarts:

---

All of this above is in addition to having trouble getting the environment to find the necessary components.

Im trying to compile and build de.setf.utility, and specifically, de.setf.utility.mime for use with
de.setf.wilbur and de.setf.resource systems. Each of these (resource and wilbur) are quite valuable for the CL community.

In 2024 QL:Quickload is absolutely able to accommodate building these systems. I understand wanting to keep building these systems independent of QL, but QL and derivative tools are bog standard for use with CL at this point, and it really ought to be possible to refactor your systems for use with QL. At the very least, you're currently distributing systems with their own internal adhoc extensions to ASDF, your extensions are in addition to the ASDF shipped with sbcl, and that shipped with quicklisp.

If you aren't willing/able to refactor your build approach to work within the existing ASDF 3.3.X protocol, can you please at least at some additional notes/comments/discussion to too level de.setf. readmes regarding your ASDF registry linking scheme for other users. Although maybe these types of ASDF configs should be obvious to older CL hacks used to building systems pre QL/pre ASDF 3, in the decade and half since QL debuted some things have changed in the greater CL community vis a vis system development, namely UIOP, ASDF 3.3, QL, and Unicode UTF-8 default encodings, Threading support, Qlot, Roswell, etc. It is increasingly difficult to keep and maintain a working mental map of all the different and disparate build protocols and layers, tracking a unique and system specific build protocol like de.setf. only adds to the cognitive load.

The Resource and Wilbur components of your systems are quite valuable to the community and will continue to be of value for a long time to come if users can reliably build your systems for inclusion in their projects. I have been building your systems since circa 2010 and have consistently found them frustratingly idiosyncratic in their approach, and it is very unfortunate to find that not much has changed in the time that has passed since. Please reconsider your position. I would be happy to help out and test builds on systems if so.

Thanks again for developing, maintaining, porting, and sharing your code and tools with the CL community. 😁✌️