WARNING: System definition file ...

Stas Boukarev stassats at gmail.com
Thu Oct 12 11:17:38 UTC 2017

Yes, SBCL has a deprecation process that goes through several stages which
span several years. QUIT signals a style-warning, not warning, and is
unlikely to ever signal a warning and will never go away.

If you're willing to fix all the affected systems just go through
quicklisp, it'll have plenty. But maybe that should be done before
introducing new warnings.

On Thu, Oct 12, 2017 at 2:05 PM Faré <fahree at gmail.com> wrote:

> On Thu, Oct 12, 2017 at 6:00 AM, Stas Boukarev <stassats at gmail.com> wrote:
> > I get 12 warnings with "System definition file  contains definition for
> > system . Please only define and secondary systems with a name starting
> with
> > in that file." while loading a single project.
> >
> These are valid warnings, and those systems must be fixed. Can you
> give me a list of the affected systems, so I may send patches
> upstream?
> Background: Secondary systems (systems loaded in a .asd file beside
> the "primary" system that the .asd file is named after) that do not
> follow the / convention can't be found by name by ASDF before the .asd
> file is loaded; they can clash with other systems and then cause
> "interesting" behavior. They were an abuse that kind of worked but not
> really from the bad old ASDF 1 days. ASDF 3 fully supports secondary
> systems, but requires them to start with a prefix of foo/ where foo is
> the primary system name (that the .asd file is named after). The old
> behavior is still supported at this time, but we started issuing
> warnings this year, together with other deprecation warnings.
> > How do I disable these warnings? If we are to update ASDF in SBCL I want
> to
> > make the asdf.lisp version bundled with SBCL to have them disabled by
> > default.
> >
> The best way to disable to warnings is to fix the 12 affected libraries.
> If you modify ASDF to remove that message, please change all
> occurrences of "3.3.0" to "" in the sources, too, to indicate
> one local change.
> > And if some future version of ASDF stops loading any of the 12 libraries,
> > then I just won't update SBCL to that ASDF version.
> >
> ASDF won't stop supporting that feature for at least the next 2 years.
> Those 12 libraries will have that much time to be fixed. If the last
> maintainers have quit, the libraries will have to be taken over by
> e.g. sharplispers some time before then.
> Experience shows that 2 years is about the time it takes for some
> change to "fully" propagate through the Common Lisp community (e.g.
> for a new version of ASDF to be used by all implementations). It is
> not an unreasonable target for backward compatibility of ASDF. I see
> no good reason to keep 15 or 26 year old bugs around indefinitely.
> SBCL does introduce new warnings at times, that sometimes affect tens
> of existing systems (e.g. the quit / exit renaming). I see no
> principled reason for SBCL to shy away from legitimate warnings from
> ASDF. How long did SBCL maintain backward compatibility with the old
> calling convention?
> PS: I wrote a function
> ql-test:find-misnamed-secondary-asdf-systems-in-quicklisp in my system
> ql-test https://gitlab.common-lisp.net/frideau/ql-test and it finds
> 330 suspect defsystem entries in quicklisp. Some are templates that
> can be ignored (and probably filtered out of this function), but most
> are legitimate issues that must be fixed in the next two years.
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> If debugging is the process of removing bugs,
> then programming must be the process of putting them in.
>         — Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20171012/21d39451/attachment-0001.html>

More information about the asdf-devel mailing list