[asdf-devel] patch for component-relative-pathname

[Robert Goldman]

On 2/22/10 Feb 22 -10:02 AM, Faré wrote:
>> I am inclined to agree.  I'd be happier if we could just say something like
>>
>> (:file "foo" :relative-directory "bar")
>>
>> instead of
>>
>> (:file "bar/foo")
>>
> Why? You're just moving the complexity around,
> without simplifying the overall design.
> Moreover, the astute user is already familiar with /-separated paths
> (from URLs if not from his filesystem) and
> the second notation leverages this familiarity.
> Which comes very handy when files are shuffled around.
> Finally, we need to parse names if only to portably handle the
> :static-file "foo.lisp" case -- why can't we parse paths at the same time?
> 
> Least surprise: reuse familiarity with filesystem paths and/or URLs
> Conciseness: fewer slots that get out of sync
> Generality: share the same mechanism with :static-file "foo.lisp"

Counterargument:

Confusion/duplication:  Compute the component-relative-pathname through
some confusing combination of :pathname and :name.  Abuse of the :name
to provide pathname functionality.

Non-orthogonality:  Compute the pathnames of modules and files
differently (name not used to give

> 
>> For that matter, both of these are probably unnecessary now that module
>> dependencies work and we can do:
>>
>> (:module "bar"
>>   :components ((:file "foo")))
>>
> Not always doable. Especially when dependencies change and suddenly
> subdirectories are no longer perfect units of dependency.
> Been there, done that.

You don't have to map modules one to one to files.  E.g.

(:module "bar"
  :components ((:file "foo")))
(:module "bar1" :pathname "bar/"
  :components ((:file "bletch"))

Right?
> 
> I have a project here with over 1400 files, not counting libraries.
> That trick doesn't work.
> 
> 
>> So, question:  Fare, do we really need the additional hair now that
>> intra-system module dependencies work?  Wouldn't it be possible for you
>> to macrologize your names-as-pathnames extension and purge the hair from
>> the core of ASDF?
>>
> The hair is in the notion of CL pathnames itself. Get rid of it.
> How do you think this feature can be modularized anyway?

I don't agree.  I think the hair comes from putting pathname computation
into two places:  into the name and into the :pathname.  I'd rather see
all the pathname computation delegated to the :pathname argument.
> 
>> I'd love to see all this extra code get purged....
> I disagree. If you compare with the *broken* mess that was before
> and led to non-portable behavior in :static-file "foo.lisp",
> then no, this is not extra code. This is *less* code than was before,
> for more functionality, and in a more portable way.
> 
> The feature is now solved. It is a bug in the documentation
> if it says otherwise.
> 
> Actually, now that I think of it, for portability reasons,
> and to avoid all these ugly :pathname #.(make-pathname ...)
> any string argument to :pathname should be processed through
> component-name-to-pathname-components. You can still #p"..."
> if you want your system's non-portable parse-namestring, or
> #.(make-pathname ...) if you are crazy about it.
> 
> Currently, :pathname <string> is non-portable and thus USELESS.

I'd rather fix :pathname than add hair to name....

Cheers,
r