Looking at Stelian's recent patches to iolib, I saw that he uses things like:
(asdf:defsystem :iolib.syscalls ... :pathname #-asdf2 (merge-pathnames "syscalls/" *load-truename*) #+asdf2 "syscalls/" ...)
This shocked me, as I new (for having been hit badly by the issue at ITA and having read the code) that you can't use (merge-pathnames ...) like that in a component and need #. instead, since there is no EVAL in parse-component-form. ITA used to have lots of #.(merge-pathnames ...) before I implemented / parsing in our local ASDF (now merged into ASDF 2).
Well, it turns out that the defsystem macro itself treats :pathname specially and lets that argument be evaluated unlike other arguments and unlike :pathname for other forms. This interacts badly with some code I've written recently that cleans up the way we normalize specified pathnames for components, my code assuming we were always provided a valid specifier.
So the question is: what to do?
1- Should I do nothing, thus having more uniform semantics but breaking compatibility with ASDF 1 and requiring users of defsystem to use #. in such occasions?
2- Should I issue an ASDF 2.0 minor release that re-allows pathname evaluation just for defsystem forms (excluding other forms), thus providing better backwards compatibility?
3- Should I issue an ASDF 2.0 minor release that does pathname evaluation inside parse-component-form, thus providing better backwards compatibility AND extending the semantics so that it be more uniform?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A common man marvels at uncommon things; a wise man marvels at the commonplace. — Confucius