(Sorry for an almost year-late comment.) Note that for many years ECL has been shipping with its own "ASDF 3.1.8" forked from our 3.1.7 instead of adopting 3.2.0 (we never released a 3.1.8). What more, its maintainer has refused to work with the ASDF maintainers to even discuss which use cases we failed to properly support, so we could fix them and amend our test suite. I haven't been following this for years, though, so can't speak of the current status for sure, though I suspect things haven't changed.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org “When everything seems to be going against you, remember that the airplane takes off against the wind, not with it.” — Henry Ford On Thu, Jan 2, 2025 at 5:00 PM Robert Goldman <[email protected]> wrote: > > On 1 Jan 2025, at 16:33, Joseph Mingrone wrote: > > As you can see, in this particular case, the ASDF package itself is > being built. For CCL, CLISP, and SBCL, everything works as expected, > and the FASL files are written under /wrkdirs/. However, when building > packages for ECL, ASDF tries to write the FASL files to > ${HOME}/.cache/common-lisp, which fails due to restrictions in our > package-building tool. > > I noticed some #+ecl conditions in uiop/lisp-build.lisp, but have not been > able to pinpoint the issue. The ECL maintainer guessed that ASDF might fail > to write to the expected location because it's trying to rename files between > different mount points when POSIX says it should copy them. I haven't had a > chance to check the source, but it seems like this explanation is probably > wrong. Here's why: if the problem was not being able to write to the expected > location, I don't believe that the code would fall back to writing in > ~/.cache. I would have expected the output translations to fail and the fasl > file (possibly with a temp name) be left in the compilation directory. > > To debug, the first thing I would do is look at what's in > asdf/output-translations::*output-translations* when running in ECL and > compare that with what's there in one of the implementations where the output > translations are working properly. That will tell us if the OT specifications > are being processed correctly, at least. > > If that looks good, then I would see what happens with some calls to > asdf/output-translations::apply-output-translations in the REPL. If you find > errors there, please post a bug to the ASDF issues site. If you don't please > email again and we can try to figure out what's going wrong. > > Worst case, you could modify your copy of ASDF to add a call to (trace > asdf/output-translations::apply-output-translations) and see what happens > then. > > Also, are you using this with ASDF taken from our git repo? It looks like you > are working with some packaged version. Please see if you get the same > behavior after loading the latest asdf.lisp instead of whatever is coming > from FreeBSD.
