[mcclim-devel] Errors installing McClim

[Nikolaus Demmel]

Am 13.07.2010 um 14:21 schrieb Robert Goldman:

> 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.

I agree with you. I did understand you wrongly and as you said we were talking at cross-purposes. Sorry.

Best regards,
Niko