ASDF configuration and cache

[Faré]

On Wed, Apr 29, 2015 at 2:00 AM, Mark Evenson <evenson at panix.com> wrote:
> On 2015/4/29 10:03, Faré wrote:
>> Dear Mark,
>>
>> ~/.config/common-lisp/source-registry.conf.d/ is being used because
>> you're compiling on Unix. If you were using Windows, it would be using
>> something else based on LOCALAPPDATA, not USERPROFILE.
>
> Hmmm.  Do you mean "compiling [ABCL] on Unix"?  That is not the case, as
> the ABCL being used has been compiled on the Windows host.  And the
> creation of the WAR artifact for production is also happening on the
> Windows host.
>
> While running on Windows, everything *is* being compiled "under" Cygwin.
>  Maybe that is the cause?
>
If you have :unix in your *features*, then ASDF decides that ABCL is
running on Unix. Is that not a correct criteria? Are you enabling
:unix because of cygwin?

Looking at the code, I realize that it was misinterpreting the XDG
standard in consulting ~/.config/ in addition to the XDG_CONFIG_HOME
(when defined) rather than instead of it as a fallback as undefined —
fixing this bug originally reported by Jason Miller was the initial
reason for this upheaval of configuration paths. This made that path
work under Windows when it wasn't actually meant to work. Ouch. On
Windows, I intended only the local-appdata and else appdata to be
consulted. Ouch. So fixing the code means we'll be
backward-incompatible, anyway. Ouch.

Well, we might as well do the Right Thing™ if we're going to break
compatibility anyway. What is the Right Thing?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If all values are relative, then cannibalism is a matter of taste.
        — Leo Strauss




>> For reliable builds, especially ones that create cross-platform
>> objects, we recommend you don't use either, but explicitly pass a
>> proper (or null) overriding configuration to the initialization
>> functions initialize-source-registry and
>> initialize-output-translations.
>
> I'm a little unsure what you are suggesting here, perhaps because I am
> using a strategy outside of the "normal" use of ASDF.  This strategy can
> roughly be described as follows:  At build time for the WAR, I need to
> locate all the ASDF systems in a running ABCL image.  This allows me to
> package both Quicklisp available systems with local ones in a consistent
> manner that freezes their versions, and doesn't rely on access to the
> network at production time.  Then I iterate across all the dependencies
> performing an rsync of all the source artifacts into  a designated build
> directory that is subsequently packaged in the WAR deployment artifact.
>  Here, I assume that the ".asd" file lies at the top of the source
> artifact file hierarchy, an assumption which seems to largely work with
> the ASDF systems I am utilizing at the penalty of including sub ".asd"
> systems twice (since they are the same system, this inefficiency doesn't
> really matter although it should be cleaned up).  At runtime, I use
> ASDF:INITIALIZE-SOURCE-REGISTRY to explicitly refer to the directory
> containing the source artifacts, which is now located within the WAR
> artifact.  ABCL pathnames are able to specify locations within the zip
> file which constitutes the WAR artifact.  After this manual
> configuration of the source registry, the systems are available by the
> usual ASDF:LOAD-SYSTEM mechanism.
>
> Under this scheme is there an application of "proper (or null)
> overriding configuration" that you recommend using?
>
> Best,
> Mark
>
> --
> "A screaming comes across the sky.  It has happened before, but there
> is nothing to compare to it now."