[asdf-devel] Logical pathnames vs ASDF & SBCL
james.anderson at setf.de
Sun Jun 12 09:34:36 UTC 2011
good morning, faré, gentlemen;
On 2011-06-12, at 02:25 , Faré wrote:
> TL;DR: ASDF currently doesn't play so well with logical pathnames.
> I'm seeking advice on how to make things better —
> or on whether it's worth the trouble.
> Dear all,
> POTENTIAL SOLUTIONS
> Finally, I could do nothing, and assume that
> people who go through the pain of setting up logical pathnames
> before they run ASDF can just as well setup the *central-registry*
> and have LPNs be recognized in the good old way.
> If you use the source-registry, your LPNs will be squashed,
> and nothing will break in the code since code works fine with PPNs,
> just like most everyone use it, but your debug information
> will be stored according to the PPN, not the LPN. Meh.
less might well be better.
a bit over twenty years ago, when i had sent a library to john
mallory to be included among cl-http contributions, he pointed out to
me, that, as my apparent intent was to implement portable systems for
others' use, it was not a good idea to have used mixed case
pathnames. i trusted him, renamed several dozen files and
directories, and have adhered to that restriction ever since. over
the years, i have seen nothing to contract his advice. furthermore,
over these years, as my requirements for lisp system management tools
have remained limited to those related to building those aspects of
larger systems which comprise just lisp source code, i have observed
that portability and maintainability are improved by adopting the
logical pathname naming restrictions for system description
components. that is, in distinction to experience reported elsewhere,
it has been possible to use asdf system declarations which contain
just logical pathname components with all lisp implementation which
purported to support logical pathnames. the pathname regression test
which i implemented during the "asdf 2" testing process demonstrated
this to have been true for all of the variations of runtime and
pathname expression which were known at that time.
my particular build process - even prior to "asdf 2", involves
variations on the two alternatives discussed in faré's original
message [cf. https://github.com/lisp/de.setf.utility/blob/master/asdf/
- it searches for system definition files recursively from the set of
root directories specified in *central-registry*. for my own systems,
a method to interpret system names as hierarchic paths speeds the
process. this means that the *central-registry* is sufficient.
- it takes the "hard way out", as that serves maintainability. where
possible, an additional step in the system initialization protocol
derives and asserts a logical pathname root for the system, which (at
least at last check) yields logical source pathnames for all system
this approach does limit the mechanisms available to include external
libraries in my own builds. that is ok. for example, while i may use
something like quicklisp to obtain source code, i have seen the
difficulties which even advanced dependency-based build systems, such
as ruby's, introduce into production environments. it is a nightmare
to which i do not intend to submit. i prefer, that production systems
always include self-curated source code. in this case, it is a minor
issue to normalize system names.
given this use case, there has been no advantage to rely on that
aspect of the "asdf 2" effort which re-implemented the logical
pathname mapping facility. the system i have in production
[www.dydra.com] comprises 80 systems. many of them open-source. all
of which manage under these restrictions. as do the libraries which i
have made available as open source [github.com/lisp/]. so long as the
*central-registry* and the mechanisms which depend on it continue to
support logical pathnames, it will be possible to use asdf. in
particular, it is a really good thing that component pathnames for a
system which has a logical pathname root remain logical pathnames, as
that makes it possible to use standard language operators to remap
file trees for built systems during release and/or maintenance.
best wishes for your continued efforts.
More information about the asdf-devel