Skip to content
  • mevenson@1c010e3e-69d0-11dd-93a8-456734b0d56f's avatar
    Refactor PATHNAME implementation details to tighten existing semantics. · 094f6d21
    None of this should change the behavior of CL:PATHNAME, but it
    prepares for that in subsequent patches to address problems in merging
    when the defaults points to a JAR-PATHNAME.
    
    Fix COMPILE-FILE to work with source located in jar archive.
    
    Moved Utilities.getFile() to instance method of Pathname which makes
    more logical sense.  Moved Utilities.getPathnameDirectory() to static
    instance classes.  These functions no longer merge their argument with
    *DEFAULT-PATHNAME-DEFAULTS*, as this should be done explictly at a
    higher level in the Lisp calling into Java abstraction.
    
    RENAME-FILE no longer on namestrings, but instead use the result of
    TRUENAME invocation, as namestrings will not always roundtrip
    exactly back to PATHNAMES.
    
    POPULATE-ZIP-FASL no longer forms its argumentes by merging paths,
    instead using MAKE-PATHNAME with controlled defaults.
    
    SYSTEM:NEXT-CLASSFILE-NAME and SYSTEM:COMPUTE-CLASSFILE-NAME changed
    to NEXT-CLASSFILE and COMPUTE-CLASSFILE returning PATHNAME objects
    rather than namestrings.
    
    Compiler now dumps pathname in alternate form that preserves DEVICE
    :UNSPECIFIC.
    094f6d21