monolithic-concatenate-source-op misses a few dependencies

[Ben Vulpes]

Fare et al.,

The Postmodern/usocket problem I encountered was in fact due to
cl-postgres not setting a feature flag in an :execute context:
https://github.com/marijnh/Postmodern/blob/57dc8cb4acc4599aee757e8f81999a0fa83c7111/cl-postgres/features.lisp#L8
. To digress from the list topic for half a second, this confuses me,
as that code refused to execute until I patched cl-postgres at that
point to also eval-when in :execute, even when loading the
concatenated sources with sbcl ... --load full-concatenation.lisp

More relevant to the list, other observations include: chipz mutates
*features* in :chipz-system, a package defined in chipz.asd, which
causes problems because the .asd files are not concatenated with the
sources (not suggesting this is something asdf should even concern
itself with); and both drakma and usocket call (asdf:component-version
(asdf:find-system ...)) at read time, which fails to find the package
in question when loading the concatenated source on a machine without
those packages in *central-registry*, because (I believe) as noted
above, monolithic-concatenate-source-op doesn't include system .asd
files. Again, I'm not suggesting that this behavior change.

Yours,
Ben

On Sat, Oct 14, 2017 at 11:52 AM, Faré <fahree at gmail.com> wrote:
> On Sat, Oct 14, 2017 at 1:17 PM, Robert Goldman <rpgoldman at sift.info> wrote:
>> Will you please clarify for my benefit, since I don't actually use any of
>> the image operations.
>>
>> Is the problem that somewhere in the process of loading Postmodern, or one
>> of its dependencies, some bit of code invokes REQUIRE? Or is this an issue
>> with ASDF's REQUIRE-SYSTEM.
>>
> monolithic-concatenate-source-op is supposed to create a source file
> that has "all the (transitive) source code required to load a system".
> Problem is, it is naive in that the current implementation believes
> there are only source files to concatenate. And so it doesn't handle
> (:require "foo") dependencies which would require to generate a
> temporary "source file" that contains (require "FOO") in it — or
> better a refactoring such that instead of source files, you use
> arbitrary arguments to vomit-output, and for require dependencies you
> use a function that outputs that instead of a pathname  (and wrap a
> map () 'vomit-output in a with-output-file).
>
>> If it's the former, then I believe this is simply a bad implementation in
>> the relevant system.
>>
>> If it's the latter, we should do something about it. However, I believe that
>> REQUIRE-SYSTEM, despite its name, doesn't actually use REQUIRE, instead it
>> "acts like require."
>>
> Well, there are unhappily two things called "require-system": the
> class that backs the (:require "foo") dependencies, and the function
> that is now deprecated because it didn't have a good composable
> meaning in presence of multiple build phases. The one that matters
> here is the former.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> All problems in computer science can be solved by another level of indirection
>         — David Wheeler
> Almost all programming can be viewed as an exercise in caching
>         — Terje Mathisen, well-known programming optimization guru



-- 
Ben Vulpes
503-313-5838
MAVN