On Thu, Sep 4, 2014 at 2:58 PM, Robert Goldman rpgoldman@sift.net wrote:

Faré wrote:

...

On Thu, Sep 4, 2014 at 9:49 AM, Ralf Mattes rm@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.