<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 30 Jan 2018, at 15:53, Attila Lendvai wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">I haven't used CFFI in a while.</p>
</blockquote><p dir="auto">TL;DR: is this a sane fix?<br>
<br>
<a href="https://github.com/cffi/cffi/commit/4b9b06f15912e823581b1aeb8a0d5c2ef11f702d" style="color:#777">https://github.com/cffi/cffi/commit/4b9b06f15912e823581b1aeb8a0d5c2ef11f702d</a><br>
<br>
----------<br>
and here follows the elaborate email that led me to find the above<br>
solution:<br>
<br>
a bit of background: it's a subsystem of CFFI that generates the CFFI<br>
bindings from a json file, that is in turn autogenerated from the C<br>
source.<br>
<br>
so,<br>
<br>
1) C -> json<br>
2) json -> lisp (CFFI definitions)<br>
3) asdf compiles/loads the generated lisp file<br>
<br>
1) requires a heavyweight infrastructure (a binary run by<br>
run-program), so there's support to do that lazily, and just<br>
distribute the json files generated once by the lib author.<br>
<br>
2) is relatively lightweight, but it still requires loading a broader<br>
scope of lisp dependencies, so there's support for the lib author to<br>
run the generation and distribute the generated lisp file.<br>
<br>
now, whether the generator code (extra dependencies) is needed is<br>
decided by whether or not the generated lisp file is up-to-date.<br>
<br>
unfortunately i cannot test it properly because of another bug/change<br>
that i'll report in a separate thread.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Thinking out loud:</p>
<p dir="auto">I'll have a bit more of a look. IIUC what you are saying is that there should be an OP that covers the C -> JSON translation, and that requires some infrastructure that you don't want to load unless it's necessary.</p>
<p dir="auto">Then there's JSON -> lisp that has additional dependencies that are optional.</p>
<p dir="auto">The problem I see is that, IIRC, ASDF creates a build plan that is <em>unconditional</em>, and then <em>executes</em> it conditionally, by calling <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">OPERATION-DONE-P</code>, and skipping unnecessary operations. It does this because earlier steps in the process can change what <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">OPERATION-DONE-P</code> would return for later stages in plan execution.</p>
<p dir="auto">The problem with this is that you want what comes <em>later</em> in the plan (whether or not the lisp derived from JSON) to affect what comes <em>earlier</em> in the plan (whether or not the JSON to lisp translation library gets loaded).</p>
<p dir="auto">I think I know what is the Right Answer to this, but it might be so much more work that you would rather just keep your current hack working....</p>
<p dir="auto">I think the Right Thing is to realize that what ASDF does is not so much transform files, as to maintain the consistency of the running lisp image. Now, in no case does the running lisp image need <em>either</em> the JSON generation system <em>or</em> the JSON to lisp translation system. All the <em>running lisp image</em> needs to function correctly is an up-to-date lisp file produced by this pipeline. So....</p>
<p dir="auto">The Right Thing is to kick that pipeline out of the current lisp process. Instead of making ASDF use its <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">LOAD-OP</code>, etc. to do this translation for you, you should just create an external application (which might be a lisp program) to do the JSON generation (if needed) and the JSON to lisp translation (if needed). That external program could well use ASDF to manage itself. But all that would be in your <em>main</em> ASDF system definition would be a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">JSON-GEN-OP</code> and a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">JSON-TO-LISP-OP</code>, each of which would be implemented by invoking an external program. As in, for example<br>
<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7"><br>
(DEFMETHOD PERFORM ((OP JSON-GEN-OP) (c json-component))<br>
(uiop:run-program ....))<br>
</code></p>
<p dir="auto">Once you think about what ASDF does and doesn't do, I think this makes perfect sense. But, of course, it might be a big pain to do so.</p>
<p dir="auto">Best,<br>
R</p>
</div>
</div>
</body>
</html>