WARNING: System definition file ...
fahree at gmail.com
Thu Oct 12 11:05:17 UTC 2017
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
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
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 "220.127.116.11.1" 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
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.
More information about the asdf-devel