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?
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