Operations on package-inferred-system
Faré
fahree at gmail.com
Fri Jul 29 03:54:46 UTC 2016
On Thu, Jul 28, 2016 at 12:48 PM, Eric Timmons <etimmons at mit.edu> wrote:
> I *really* like using package-inferred-system for defining systems,
> but I often find it doesn't behave as I expect when performing
> operations on it. I'm curious if these behaviors are intended or if
> the implementation is just incomplete.
>
> I approach package-inferred-system as a way of automatically finding
> dependencies between files and on third-party systems for a given
> system I'm writing. Under the hood, I know it makes a new system for
> every source file, but I consider that just an implementation detail
> and that when I refer to the primary system, I really mean everything
> that logically belongs to that system and not just the source files
> declared in the system's :components option. (Perhaps this assumption
> just needs to be adjusted on my end).
>
> The difference between expectation and reality often manifests itself
> in two places for me:
>
> + When I'm trying to distribute my system with a non-monolithic
> operation. E.g. `(asdf:perform 'asdf:concatenate-source-op
> :some-package-inferred-system) results in only the files explicitly
> declared in the system's :components option being concatenated.
> (Similar things happen with compile-bundle-op).
>
> + `(asdf:load-system :some-package-inferred-system :force t)` results
> in only the files explicitly declared in the system's :components
> option being reloaded.
>
> I was planning to write my own system class to address these issues,
> but figured I should see if this is even intended behavior before
> doing that =).
>
Indeed, this suggests that plan classes and bundle operations should
probably be able to accept a force / force-not argument (or the
equivalent for bundle operations) intermediate between t and :all,
such as :by-primary, that forces traversal or non-traversal based on
the primary system name.
I'm not willing to write it, but I'm willing to review it if and when
you do. This probably requires a patch to ASDF itself. Extra props to
you if you find a nice extension protocol that allows to move most of
that code outside of ASDF itself.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Yesterday I was clever, so I wanted to change the world.
Today I am wise, so I am changing myself. — Rumi (1207–1273)
More information about the asdf-devel
mailing list