[mcclim-devel] Errors installing McClim

Robert Goldman rpgoldman at sift.info
Tue Jul 13 12:21:43 UTC 2010


On 7/13/10 Jul 13 -6:53 AM, Nikolaus Demmel wrote:
> 
> Am 13.07.2010 um 00:06 schrieb Robert Goldman:
> 
>> On 7/12/10 Jul 12 -4:39 PM, Peter Busser wrote:
>>> Oliver,
>>>
>>> Well, my experience with creating lots of Common Lisp .deb packages on
>>> Debian shows that problems in most cases are caused by incorrect
>>> placement of the .asd file(s) followed by missing .lisp files or other
>>> missing stuff. Sometimes the .asd file tries to be smart by doing
>>> things that it shouldn't do (like i.e. compile C source code). The
>>> most time consuming part for me is to find the right version of
>>> libraries. Especially for larger programs with lots of dependencies
>>> like Closure, the McCLIM based web browser. Somehow I never got it to
>>> do anything useful.
>>
>> Well, for the record, compiling C source code is a perfectly legitimate
>> thing for an ASDF system definition to do (at least when not in the
>> context of a .deb).
> 
> I would disagree. Side effecting .asd files are evil and make other peoples lives very hard. (See e.g. http://www.mail-archive.com/asdf-devel@common-lisp.net/msg00949.html)

I think we are talking at cross-purposes.

It is quite possible to have an .asd file that contains a system with a
C source file as one of its components.  Loading that system would cause
the C file to be compiled but is not at all a /side/ effect --- it is an
intended effect of loading the system, of which the C file is a part.

> 
> The problem boils down to the fact, that with side effecting asd files you cannot safely determine a system's dependencies without loading the system.

As I said, I think we are talking at cross-purposes here and are not
truly in disagreement:  I am not talking about compiling a C file as a
side effect of loading the .asd file (which I agree would be wrong), but
as a main effect of loading the /system/ defined in the .asd file.  The
latter is NOT a side-effect and is explicitly supported by ASDF.

BTW, side-effects in .asd files are NOT necessarily evil and may be
/essential/.  E.g., it is possible that an .asd file relies on another
ASDF system simply in order that it can be processed.

E.g., if my ASDF system foo relies on an ASDF extension (say an ASDF
system that defines a new ASDF component subtype/subclass), then it
/must/ do this by side-effecting.

This may be somewhat evil, but there is no alternative means of
achieving it in ASDF.

This has been discussed before, and it might well be good to make .asd's
fully declarative, but they are not now.

Best,
r
> 
> Best regards,
> Niko
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 





More information about the mcclim-devel mailing list