At time if writing this reply I haven't checked out mk-defsystem 4. I
did read the design document, but that was last summer : you may
be able to find my clocc-list posts from then in the archives. So
when I refer to mk-defsystem here I'm mostly talking about the old
Marco Antoniotti <marcoxa@...> writes:
> 1 - Full reimplementation in CLOS of MK:DEFSYSTEM 3.x with internal
> protocol defined on the basis of KMP' system document
> (EXECUTE-ACTION and friends).
> 2 - Backward compatibility of sysntax with 3.x.
My feeling is that there's actually a place for both defsystems, and
this is why. asdf makes a conscious design break with mk-defsystem
(3) in several places: most notably its treatment of "what are the
parts of a system". An asdf system consists only of the source files
whereas an mk- system is source files plus the files generated by the
compile-system operation - as implied by :binary-extension and
suchlike keywords. Fitting these into the asdf model would be
somewhere between ugly and nonsensical, so I took the decision to
(We don't directly support make:define-language either, for the same
kind of reason)
> 3 - Operating System and File System Independence (no dependence on
> UNIX file system conventions)
Paolo asked about this as well. For the record, asdf uses common lisp
pathnames throughout, but with the following departures from
'recommended practice': (1) we use :case :local, and (2) if you name a
component using a symbol, the corresponding pathname is computed using
the downcased symbol name. So when I say "unix-like", the actual
requirements are (a) "preferred case is lowercase, and/or filesystem
will uppercase filenames if they are supplied in lowercase" (works for
Unix, Mac, DOS, LPNs), and (b) "filesystem is hierarchical" (a
necessary condition for "useful" IMHO :-)
If you can do better than that without forcing me to write
"iNVERSEcAMELcASE.JAVA" for my java class source files, I am eager to
see and steal your solution ;-)
> 4 - Full dynamicity of component definitions
> 5 - Provision for multiple dependencies
> 6 - Provisions for versioning.
Not sure what you mean by those without more detail, but I daresay
it'll be clearer when I look at the actual code. asdf has version
checking but no actual version updating - which I think is best left
to something layered.
> 7 - Integrated support for multiple external compilers (what if you
> want to use MS cl and cygwin gcc? Or SunPRO cc and gcc?)
Adding this to asdf is a SMOP: it's not done (in fact, there's no
external compiler support _at all_ directly in asdf right now, but an
example showing the necessary six lines of code to define the
appropriate operations is in db-socket.asd, for anyone interested) but
there's nothing fundamental which would make it messy.
> The system is not perfect by any means and it has no serious
> documentation. If you like, you are most welcome to play with it.
I'll be doing exactly that as soon as I have time. Thanks for your mail.
Do you have any opinions on the asdf design or code?
(In general, if the Unix world can support incompatible GNU and BSD
makes, I don't see why CL can't support more than one system definition
utility too. The more people thinking about this stuff, the better, IMO)
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources