On Thu, Sep 4, 2014 at 2:58 PM, Robert Goldman <rpgold...@sift.net> wrote: > Faré wrote: >> On Thu, Sep 4, 2014 at 9:49 AM, Ralf Mattes <r...@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. _______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
