Shinmera
commented
8 years ago There should be restarts for every failure that let you try to redownload the archive for every step instead of having to clean things out manually and reissuing the command. I can't help you beyond that without knowing more about what your particular failures were or how they happened.
Usually I do use the standard initialisation code that pulls in Quicklisp and everything. The only thing you must exclude for sure is Slime/Swank as that would start threads, making your image unable to be deployed. The reason why I still use my standard init file that pulls in Quicklisp is what you essentially discovered-- ASDF is a pain to manage on your own. If you absolutely want to exclude Quicklisp from your distributed image, you can use ql:write-asdf-manifest-file to generate a file listing all the active ASDs in their proper order for you. You can then use this file to tell ASDF where to load the systems from. I haven't ever used this myself however, so I can't really tell you how to go about it in exact steps.
In order to understand what makes it crash, you have to launch your generated binary from the Windows command prompt. That might give you some sort of clue as to where it's failing.
jkordani
Hello Shinmera!
I have finally gotten qtools up and running on windows 7 64 bit, using a 32 bit ccl following the qtools github.io page but I'm having problems when I get to the deploy step.
For starters I noticed that when I initially tried to quickload qt-libs, it took several issuances of the command and a purge of the resultant standalone directory to finally succeed in getting past the (ql:quickload '(qtools qtcore qtgui)) step. In each attempted load of the qt-libs library, different things seemed to happen at each step. I chalked this up to a potentially flaky internet connection on my part, and I apologize for its vagueness, capturing a log of this would have spanned several image restarts, I apologize for its vagueness.
Once I was able to successfully invoke the (with-main-window call from your demo code, I attempted to walk through the deploy steps and this is where I ran into issues. Taking a cue from your suggestion that things would probably work best trying to deploy from an image with no extra initialization, I tried the following command line.
C:\Users\bullshit user>ccl32 --no-init --load c:\Users\Public\Documents\ccl-trunk\tools\asdf.lisp -e "(asdf:operate :build-op :qtools-intro :force T)"
My first problem was that I needed to configure asdf to find the project in the quicklisp local-projects, and then once asdf couldn't find the quicklisp-sourced qtools, I added the quicklisp/software folder to the registry search as well.
I now realize that since I have multiple versions of qtools and associated libs in my quicklisp distribution from numerous upgrades over time, that it is likely that a barebones asdf library search is probably picking up a random sampling of the appropriate libs from the quicklisp/software folder as opposed to whatever quicklisp does to provide only the most recent libs, and so I am here to ask, given that you expect users to find qtools from quicklisp but then base applications off of it (likely sourced from local-projects or other user specified locations outside of quicklisp, when deploying, how should everything be set up in order to deploy with the correct libraries located? As it stands my efforts have resulted in binaries that crash or don't display a window at all, but I suspect is because I'm not pulling in everything cleanly.
Any help would be greatly appreciated.