[Asdf-devel] Semantics of asdf:system-relative-pathname

[Faré]

On Thu, Sep 4, 2014 at 2:58 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> Faré wrote:
>> On Thu, Sep 4, 2014 at 9:49 AM, Ralf Mattes <rm at mh-freiburg.de> wrote:
>>>   (defsystem "foo-test"
>>>      :version "0.1"
>>>      :pathname "t"
>>>      :serial t
>>>      ..... )
>>>
>> (asdf:system-source-directory (asdf:find-system "foo-test")) ;=>
>> #p"/home/ralf/src/foo/"
>> (asdf:component-pathname (asdf:find-system "foo-test")) ;=>
>> #p"/home/ralf/src/foo/t/"
>>
> IMO, there is no *perfect* solution to this problem, and the current
> behavior is "as right as possible."
>
Looking at the source, the system-source-directory is more primitive
than the component-pathname, and indeed serves as one of the primitive
inputs from which a system's component-pathname is computed.
Therefore, it has to remain a separate function.

Now, should the system-relative-pathname function be based on
system-source-directory or on component-pathname? I can see arguments
both ways. Whichever it goes (and certainly, it shouldn't be changed
without at least surveying how that affects systems in Quicklisp), it
should probably be documented.

> this just shows that the top-level use of :pathname (instead of using a
> module) is problematic.
>
Well, a :pathname is very useful at least in the case of computed
systems not from a .asd file — and these suggest that indeed, making
system-relative-pathname relative to the component-pathname might be a
good idea, since they do have a non-nil component-pathname, but a nil
system-source-directory.

> On the one hand, it's clear that the programmer doesn't want any files
> to live in the top level of the system: the programmer wants the top
> level to have only the asdf file and maybe some READMEs, and make them
> more visible by pushing the sources into a subtree.  According to this
> argument, your interpretation is correct.
>
Also, he could use (system-relative-pathname foo "../bar/baz").

> OTOH, what if you have a top level foo/ directory with the asdf system
> definition and subdirectories src/ and data/?  In that case, you want
> ASDF:SYSTEM-RELATIVE-PATHNAME to be foo/ so that you have the choice of
> going to src/ or data/.
>
> In my opinion, what this disagreement shows is that top-level (i.e., at
> DEFSYSTEM) use of :PATHNAME is to be deprecated.
>
It has existed since before ASDF 2 (where indeed, it was evaluated,
unlike the :pathname in any other position — I changed that to nothing
being evaluated in ASDF 2 for consistency, and that broke a couple
systems in the wild). We use it a lot in testing ASDF itself. I don't
believe it's reasonable to deprecate it.

> If my system was
>
> (defsystem foo
>   :components ((:module "src" ...)
>                (:module "data" ...)))
>
> then the current behavior would be unambiguously correct.
>
> I think what this shows is that using :pathname at the root of a system
> definition is just wrong.  Or, perhaps, that using :pathname at the root
> of the system should be interpreted (i.e., its semantics should be
> defined) "as if" it was defining an anonymous module (since that's what
> happens -- the :pathname doesn't affect the location of the :defsystem).
>
That's kind of what happens now... except that
system-relative-pathname doesn't heed it.

> I will wait for further discussion, but IMO, this is a WONTFIX.
>
Maybe the solution is just "document the current behavior".

If Ralf or someone else things strongly of this issue (i.e. not me), I
fear he'll have to push it forward, by identifying all systems in
Quicklisp that involve both :pathname at the defsystem level and
system-relative-pathname.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Not all Law is created equal before Man. Some Law causes least conflict and
least perverse incentives. By definition we call it Natural Law.