Yes, supported: Having #p"foo.asd" define systems "foo/test", "foo/bar", "foo/baz" in addition to "foo". ASDF can even find them if you (asdf:make :foo/test) without having loaded foo first.
Unsupported: Having #p"foo.asd" define "foo-test", "bar", "foo-unparsable-mess_with.angry^#$*characters", etc.
Please use secondary systems that are properly named. I <3 secondary/systems. The slash ensures ASDF can find your secondary systems.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/51 for the proposed change: issuing a WARNING (not an ERROR, so your builds won't break, and the warning does not happen within a COMPILE-FILE either).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Clairvoyant, n.: A person, commonly a woman, who has the power of seeing that which is invisible to her patron — namely, that he is a blockhead. — Ambrose Bierce
On Fri, Nov 18, 2016 at 9:22 AM, Robert P. Goldman rpgoldman@sift.net wrote:
I don't read fare's email as forbidding secondary systems, just those that are misnamed. So I don't think he's proposing to remove features, just check compliance with the naming convention.
Maybe the proposal at hand is not described crisply enough.
Sent from my iPad
On Nov 18, 2016, at 07:58, Mark Evenson evenson@panix.com wrote:
On 18 Nov 2016, at 14:40, Faré fahree@gmail.com wrote:
On Fri, Nov 18, 2016 at 8:36 AM, Mark Evenson evenson@panix.com wrote:
I'd like to forbid such misnamed systems. Now a quick grepping through Quicklisp (see latest update to my ql-test) finds 233 .asd files with such misnamed secondary systems. Obviously it will take time to clean up the mess, so for after the next release, I'd like to signal a full WARNING when the condition is detected, and at some point, make that a CERROR, then later an ERROR.
I object on the grounds of widespread adoption. At least it will leave me on the current ASDF for a long time.
What's wrong with issuing a WARNING until said adopting is down 95% ?
I have a substantial use of secondary systems in my personal code that will take a long time to unwind. Since it was an advertised feature of ASDF3, I expect to be around for the lifetime of that version.
As an implementor, I will patch ABCL’s ASDF3 to muffle such warnings, but to remove behavior without a bit longer warning to my user base seems unacceptable.
Please put it in ASDF4.
Sorry for being harsh, and terse, but if you are asking for opinions, I happen to have a strong one here.
With respect, Mark