SYSTEM-RELATIVE-PATHNAME has counterintuitive behavior on systems with PATHNAME

[Robert P. Goldman]

Here's a system definition I have:

(defsystem shop2/openstacks
    :depends-on (:shop2)
  :serial t
  :pathname "examples/openstacks-adl/"
  :components ((:file "package")
               (:file "domain")))

Here's what ASDF system-relative-pathname returns:

SHOP-REPLAN-TESTS> (asdf:system-relative-pathname "shop2/openstacks" "")
#P"/Users/rpg/projects/laplata/lmco-laplata/planner_distro/ext/shop2/"

What I expected it to return:

#P"/Users/rpg/projects/laplata/lmco-laplata/planner_distro/ext/shop2/examples/openstacks-adl/"

So the semantics of this function are what I would expect from

SYSTEM-DEFINITION-RELATIVE-PATHNAME

not

SYSTEM-RELATIVE-PATHNAME

I.e., it's

(defun* (system-relative-pathname) (system name &key type)
    "Given a SYSTEM, and a (Unix-style relative path) NAME of a file (or directory) of given TYPE,
return the absolute pathname of a corresponding file under that system's source code pathname."
    (subpathname (system-source-directory system) name :type type))

Note that the docstring is ambiguous because "system's source code" could mean "the source code that defines the system object" [which is what is done here] or "the source code that defines the system"

This definition gives the behavior I expect:

(defun system-relative-pathname (system name &key type)
    "Given a SYSTEM, and a (Unix-style relative path) NAME of a file (or directory) of given TYPE,
return the absolute pathname of a corresponding file under that system's source code pathname."
    (subpathname (component-pathname (find-system system)) name :type type))

I think it would be best to make this modification, although I concede it could cause some breakage.

[Faré (fahree)]

I believe the behavior was chosen for backward compatibility with common idioms that were merging pathnames with system-source-directory or such.

I have no opinion on what "should" be the behavior, except that if you change the current semantics (as opposed to the current docstring), then you should check that this doesn't cause any bad surprise with systems currently in Quicklisp.

[Robert P. Goldman (rpgoldman)]

I think the behavior was reasonable when we didn't have the "slashy" systems, but now that we do, it seems reasonable that a user would want to reference the source directory of a slashy system, instead of the parent directory where the slashy system *definition* is located together with the parent system *definition*.

What about keeping the legacy behavior and adding SYSTEM-SOURCE-RELATIVE-PATHNAME ?