(ql:quickload :genworks-gdl) fails with System "gdl-robot" not found

[avodonosov]

quicklisp 2012-11-25. sbcl-1.1.1-linux-x86 and other lisps.

When doing (ql:quickload :genworks-gdl) quicklisp doesn't even seem to download the archive from internet, just signals an error System "gdl-robot" not found.

Corresponding genworks-gdl issue: https://github.com/genworks/Genworks-GDL/issues/40

[genworks]

Welp, gdl-robot.asd is there, but the Quicklisp build for it must have failed, because it was missing its needed dependency. So it did not end up in Quicklisp's systems.txt.

genworks-gdl depends on gdl-robot (this is the simple built-in test-case for the system), therefore genworks-gdl fails. I'm a bit unsure as to how genworks-gdl made it into systems.txt when its build was failing, unless the Quicklisp test builds actually look at all .asd files in the system, rather than what's in systems.txt (I guess that must be the case - because how else would systems.txt be built up in the first place?)

So even though this was clearly an error on my part (leaving out the dependency in gdl-robot.asd), perhaps this does expose a bit of a "hole" in the Quicklisp build testing procedure? I'll leave Zach to be the judge of that.

In any case, an immediate fix for people who want to use the :genworks-gdl-20121125-git would be:

(pushnew ".../quicklisp/dists/quicklisp/software/genworks-gdl-20121125-git/" ql:local-projects-directories)
(ql:register-local-projects)

(ql:quickload :genworks-gdl)

To be safe, I would ask Zach to please notify us from now on if any of our .asd system files are failing the build tests. Also we will be happy to run those build tests locally on a frequent basis, if the tools for doing that are available.

I know previously I have told Zach (when certain .asd files were failing) that those ones "weren't important," and it looks like he started just excluding the failing ones from systems.txt and moving on without reporting them. But I see now that it is dangerous to leave any failing .asd files laying around, so I will no longer say that any of them "aren't important."

Also, we still do have some superfluous .asd files in there -- so if the build tests are sucking up too much time, we will thin them out as best we can.

[quicklisp]

There is definitely a hole in the dist construction process - no system should be included that doesn't build, and I use that behavior to watch for regressions. I'll try to figure out how this inconsistency came about.

[genworks]

Is this the issue with :gdl-surf ?

I notice that :gdl-surf is not included in releases.txt, so I'm not able to

(ql:quickload :gdl-surf)

is it because gdl-surf gave a build failure on SBCL for 20130217?

If so, I'll want to get that corrected, because we do need gdl-surf.asd to be reachable...

As a temporary workaround in order to allow (ql:quickload :gdl-surf) to work for platforms where gdl-surf does build, would it be advisable to do:

(asdf:system-source-directory :genworks-gdl) to ql:local-projects-directory and (ql:register-local-projects) ?

[quicklisp]

Another problem on my end. Sorry for this recurring issue. I'm not sure what's causing it.

That is not a great option...it would be better to copy it into some other place, I think. But it is not terrible.

[quicklisp]

Hang on - gdl-surf hasn't been included for months. This is a different issue. It contains a reference to ql:quickload, but ql is not a package that is available in the Quicklisp build environment. That kind of directive belongs in the system definition, not in a Lisp source file.

[genworks]

Thank you for the heads-up. That ql:quickload was some kind of residue which should have been wiped clean long ago. It's gone now.