[Openmcl-devel] Problem installing Hunchentoot

Robert Goldman rpgoldman at sift.info
Tue Jun 24 11:50:30 UTC 2008

Gary Byers wrote:
> A few years ago, Bryan O'Connor added some code to asdf.lisp (and
> to OpenMCL's REQUIRE) to try and get REQUIRE and ASDF to work together
> better; it's near the bottom of:
> <http://clozure.com/cgi-bin/viewvc.cgi/ccl/tools/asdf.lisp?revision=1.4&root=cvs-0.14&view=markup> 

Just as a design question --- is there some reason why it is felt to be 
important that REQUIRE be an ASDF wrapper?

I have long used Allegro Common Lisp, and they seem to have heavily 
hacked their REQUIRE to do a lot of vendor library loading.  It actually 
seems to me potentially a good thing that ASDF loading and REQUIRE be 

Not only that, but ASDF at least theoretically provides several 
operations other than just loading (e.g., at my company we are trying to 
develop a culture where we make heavy use of asdf:test-op) and it's 
possible under certain circumstances to pass additional arguments (this 
works perhaps less well than one might hope).  Further, it's my 
understanding that REQUIRE is actually somewhat deprecated.  The CL 
hyperspec says:


The functions provide and require are deprecated."

I'm not saying it's necessarily a bad thing that we do this, just that 
it's something we might want to make a conscious decision about.

> That code doesn't seem to have made it into the upstream asdf.lisp (and
> doesn't seem to be anywhere else, either), and I seem to have blithely
> clobbered Bryan's changes in:
> <http://clozure.com/cgi-bin/viewvc.cgi/trunk/source/tools/asdf.lisp?root=svn&r1=2258&r2=4703> 
> I'm not sure whether it's best to try to get Bryan's change added to
> the upstream asdf.lisp or whether it's better to just add it to
> CCL (perhaps doing runtime lookups of symbols in the ASDF package.)
> On Mon, 23 Jun 2008, Robert Goldman wrote:
>> Patrick May wrote:
>>> On 23 Jun 2008, at 23:36, Robert Goldman wrote:
>>>> Patrick May wrote:
>>>>>  I'm just starting to use Clozure on a PowerBook G4, switching from
>>>>> SBCL to get threading support on this machine.  My ccl-init.lisp
>>>>> looks like this:
>>>>> (require :asdf)
>>>>> (pushnew "ccl:tools;asdf-install;" asdf:*central-registry*
>>>>>         :test #'string-equal)
>>>>> (asdf:operate 'asdf:load-op :asdf-install)
>>>>> (setq asdf-install:*verify-gpg-signatures* nil)
>>>>> I've installed Hunchentoot successfully (at least, I see it under /
>>>>> usr/local/asdf-install) with
>>>>> (asdf-install:install :hunchentoot), but I'm unable to use it.
>>>>> When I enter (require :hunchentoot) I get the error:
>>>>>> Error: Module HUNCHENTOOT was not provided by any function on
>>>>>> While executing: REQUIRE, in process listener(1).
>>>>>> Type :POP to abort, :R for a list of available restarts.
>>>>>> Type :? for other options.
>>>>> 1 > Clearly I have something misconfigured.  Any idea what?
>>>> I think this is a simple misuse of ASDF (although I can't swear to
>>>> it).
>>>> SBCL is especially ASDF-friendly, and if you use REQUIRE, you get
>>>> ASDF loading.  Most other lisps, I believe, require (sorry) you to
>>>> use the ASDF function.
>>>> So try
>>>> (asdf:oos 'asdf:load-op :hunchentoot)
>>>> and see if that does the job.
>>>> Best,
>>>> R
>>>     Thanks for the quick response.  I should have mentioned that I tried
>>> that as well.  The error message from this approach is:
>>> > Error: Error component "hunchentoot" not found
>>> > While executing: ASDF:FIND-SYSTEM, in process listener(1).
>>> > Type :POP to abort, :R for a list of available restarts.
>>> > Type :? for other options.
>>> 1 >
>>> Do I need an environment variable set?  How can I tell where it is
>>> looking for the asdf installed files?
>> (pprint asdf:*central-registry*)
>> That tells you where asdf will look for the .asd files.
>> You can also see what
>> (asdf:find-system :hunchentoot)
>> does...
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list