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

[Robert Goldman]

On 2/21/10 Feb 21 -11:16 PM, Faré wrote:
>> 1.  SPLIT-PATH-STRING is not an ideal name.  SPLIT-PATH-STRING is /not/
>> used on paths, it is used on /names/ (in the ASDF sense of these terms).
>>  An unwary reader of this code might try to apply it to a pathname (as I
>> originally thought), where it could cause lossage because S-P-S doesn't
>> handle logical pathnames (or lots of other things about pathnames).
>> Suggest that we rename this to something like NAME-TO-PATHNAME or
>> NAME-PATHNAME-SPLIT.
>>
> What about COMPONENT-NAME-TO-PATHNAME-COMPONENTS
> or SPLIT-COMPONENT-NAME-INTO-PATHNAME-COMPONENTS

I like this suggestion.  Will make the patch.
> 
>> 2.  We should define in the grammar simple-names and structured names.
>> Simple names have no "/" and structured names may have a slash.
>>
> Where do we care? System names are not passed to the above function.

We care for two reasons:

1.  To put in the DEFSYSTEM grammar in the manual and

2.  So that people don't later on try to hijack this function to do
something for which it was not intended.
> 
>> 3.  The period character should be forbidden in /both/ simple and
>> structured names because of oddities with pathname types.
> Wait, there are plenty of (:static-file "foo.bar") around the world!
> Do you propose to make them invalid?

Ick.  Good point.  OK, have to leave those.  Note that we have already
documented that those can lead to oddities across lisps.
> 
>> 4.  Only simple names should be permitted in naming systems.
>>
> Why? System names are never parsed into paths.
> 
>> 5.  For modules, I propose either:
>>
>>   5.1 Only simple names should be permitted in naming modules, or
>>
> It's often useful to name modules that are several levels deep.
> We used to have modules with
> 	:pathname #.(make-pathname :directory '(:relative "foo" "bar"))
> and it ain't pretty.
> 
>>   5.2 The use of a structured name implicitly overrides the default
>> relative pathname for modules.  [a test should go here!]
>>
> Isn't that what's currently happening? If not, that's a bug that should
> be fixed and tested for. Sigh. Too little testing happening indeed.

It's not that it isn't happening, it's that we need to specify what
/should/ happen in the manual, for the next time someone wades in and
starts changing things....
> 
> What about we use Stefil for testing ASDF?

I'm a little reluctant to see this done, if only because I don't want to
force either additional training, or additional dependencies on the few
people who bother to submit patches.

This will make STEFIL the third unit test framework I will have to
master (NST, our own; FiveAM for the JSON library); where does this stop?

And does STEFIL handle the kinds of tests we have, where you have to
start new lisp jobs to do tests (seems like many test frameworks don't).

That said, I don't care enough to say we should /not/ do this if someone
else has the energy to do it.

> 
>> On a related note, the grammar in the manual seems to suggest that a
>> component can be just a string, which I don't believe that ASDF supports.
>>
>> The grammar says:
>>
>> component-def  := simple-component-name
>>                | ( component-type name {option}* )
>>
>> But I don't believe SIMPLE-COMPONENT-NAME is actually supported.  I
>> propose to squash this from the documentation, unless corrected.
>>
> If not currently supported, it's obviously not used anywhere, and
> can be removed in a backward-compatible way.

Done!