[asdf-devel] asdf:run-shell-command - fix, delete or don't touch?

[Faré]

>> My plan:
>> 1- declare the interface deprecated for now
>> 2- work with the authors of said software to migrate off of it.
>> 3- when no one is known to use it anymore, make it issue a warning at
>> compile and/or runtime.
>> 4- after a few versions, make it issue an error
>
> I don't think that's a full solution, per my somewhat garbled email of
> last night.  The problem is that we will end up with
>
> (defsystem foo
>  (:defsystem-depends-on xcvb-run-program)
>  ... system definition ...
> )
>
Is that a problem? I mean, beside the fact that defsystem-depends-on
only exists since 2.010 or so and is only fully supported since 2.015.12.
If that's the issue, there is still the old-style way of having
the .asd file explicitly call
	(asdf:load-system :xcvb-driver)
which is what the defsystem-depends-on does under the hood.

> The problem is that unlike before, we can't have nice
>
> (defmethod PERFORM ((op my-op) (c my-component-class))
>  (run-shell-program ....))
>
> Instead, we end up with the much nastier
>
> (defmethod PERFORM ((op my-op) (c my-component-class))
>  (funcall (intern (symbol-name #:fare-run-shell-program) :xcvb-runner
> ....)))
>
There is no such constraint in a .asd file.

Remember: a .asd file is loaded as source, not compiled as .fasl,
so it IS possible for it to load some other files that create packages
and then use symbols from those packages later in the .asd file.

So as long as you evaluate your (defsystem ... :defsystem-depends-on ...)
first, or the old-style equivalent (asdf:load-system ...), then you're good
and you can
(defmethod perform ((op my-op) (c my-component-class))
  (xcvb-driver:run-program/for-side-effects
   `(,*my-compiler* "-o" (output-file op c) ,@(input-files op c))))
and it will do the Right Thing(tm), even when the paths include spaces,
even on Windows using Allegro or ClozureCL.

Actually, you might still need a native-namestring abstraction for such
a method to work at all on implementations like SCL, and
to cover all the corner cases in other implementations like SBCL or ClozureCL.
XCVB-Driver does not yet provide such a functionality at this moment,
but may very well, in the near future.

> :DEFSYSTEM-DEPENDS-ON doesn't interact very gracefully with the package
> system....
Well, you can't use packages defined in such a system in the defsystem form
itself, but if you define your classes in the ASDF or KEYWORD package,
you're good. And really, there's no reason not to, fears of namespace
pollution notwithstanding. You know how to write a symbol whose name
want clash in practice.

In the end, I agree with you that this kind of functionality
should be a portable part of the "batteries included" with every CL system.
I just don't think it belongs to ASDF itself, since ASDF can run without it,
and we want to keep ASDF minimal, and what's currently in ASDF for legacy
reason seems both broken and not widely used (the latter probably because
of the former).

My plan of deprecating asdf:run-shell-command still holds so far.
But before I declare the function officially deprecated,
I'll make sure a better replacement is widely available.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org