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