<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 12, 2017 at 5:22 AM Faré <<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 11, 2017 at 9:14 PM, Stas Boukarev <<a href="mailto:stassats@gmail.com" target="_blank">stassats@gmail.com</a>> wrote:<br>
> 3.3.0 issues a barrage of new warnings about something it has decided is<br>
> uncouth now.<br>
><br>
On what systems is it issuing warnings? Any free software that we can patch?<br>
<br>
Without specific warnings coming from specific libraries, it's hard to<br>
tell what can be fixed, what cannot, what is an actual problem with<br>
the code you're using, what is possibly a problem about ASDF itself,<br>
etc.<br>
<br>
Odds are, the something had been decided as uncouth long ago, and ASDF<br>
just lacked the means to warn you about it.<br>
<br>
> I really have no wish to stare at these warnings coming from third party<br>
> libraries, especially since they're never going to be fixed.<br>
> Is the old behavior posing problems? Is the old behavior going away soon?<br>
><br>
Yes, some old behavior is posing problem and has for years. Sometimes<br>
the old behavior has already gone away and/or is precariously emulated<br>
in slightly incompatible ways using the newer better interface.<br>
Sometimes we really want to get away from a really bad interface that<br>
has been deprecated for years (e.g. run-shell-command, which is a<br>
security liability in addition to been challenged with usability).<br>
Sometimes a recent refactoring made some operation non-sensical (e.g.<br>
operation-on-warnings) and/or not so useful (e.g. require-system), or<br>
a really bad interface to the system (system-registered-p).<br>
<br>
Depending on the interfaces, the old behavior may go away within two<br>
year, especially where supporting it is problematic and/or the<br>
interface is bogus and misleading and not properly doing what it was<br>
once advertised to be used for. Well, whoever is maintainer then will<br>
probably do something conservative that preserves compatibility (with<br>
some kind of warning) wherever it isn't an encouragement to writing<br>
nonsensical code.<br>
<br>
> This is why I don't update ASDF, I don't want to change anything in my code<br>
> because of a new version.<br>
<br>
Last I heard, janderson was using his own slightly forked ASDF 1, and<br>
some russians had forked ASDF 2.<br>
<br>
On the other hand, some programs depend on a recent ASDF, such as<br>
IOlib or CFFI, or scripts that depend on a fixes run-program or on its<br>
younger sibling launch-program, especially so on SBCL/Windows.<br>
<br>
There is no pleasing everyone, but there's going forward. SBCL also<br>
sometimes deprecates some old interfaces, and issues warnings to those<br>
who use them.<br>
<br>
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
Every four seconds a woman has a baby.<br>
Our problem is to find this woman and stop her.<br>
</blockquote></div></div>