lib/sod.h: New macro `SOD_INSTBASE' to find the allocated base address.

[sod] / pre-reorg / sod.asd

;;; -*-lisp-*-
;;;
;;; System definition for SOD
;;;
;;; (c) 2009 Straylight/Edgeware
;;;

;;;----- Licensing notice ---------------------------------------------------
;;;
;;; This file is part of the Simple Object Definition system.
;;;
;;; SOD is free software; you can redistribute it and/or modify
;;; it under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 2 of the License, or
;;; (at your option) any later version.
;;;
;;; SOD is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with SOD; if not, write to the Free Software Foundation,
;;; Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

(cl:defpackage #:sod-package
  (:use #:common-lisp #:asdf))

(cl:in-package #:sod-package)

;;;--------------------------------------------------------------------------
;;; Definition.

(defsystem sod

  ;; Boring copyright stuff.
  :version "1.0.0"
  :author "Mark Wooding"
  :license "GNU General Public License, version 2 or later"

  ;; Documentation.
  :description "A Sensible Object Definition for C."

  :long-description
  "This system implements a fairly simple, yet powerful object system for
   plain old C.  Its main features are as follows.

     * Multiple inheritance, done properly (unlike C++, say), with a
       superclass linearlization algorithm, and exactly one copy of any
       superclass's slots.

     * Method combinations, and multiple flavours of methods, to make mixin
       classes more useful.

     * The default method combination doesn't depend on the programmer
       statically predicting which superclass's method to delegate to.
       Multiple inheritance makes this approach (taken by C++) fail: the
       right next method might be an unknown sibling, and two siblings might
       be in either order depending on descendents.

     * Minimal runtime support requirements, so that it's suitable for use
       wherever C is -- e.g., interfacing to other languages."

  ;; And now for how to build it.
  ;;
  ;; The big tables in parser.lisp need to be earlier.  CLEAR-THE-DECKS ought
  ;; to do more stuff, including calling BOOTSTRAP-CLASSES.  Generally, the
  ;; code isn't very well organized at the moment.
  :components
  ((:file "package")
   (:file "utilities" :depends-on ("package"))
   (:file "tables" :depends-on ("package"))
   (:file "c-types" :depends-on ("utilities"))
   (:file "codegen" :depends-on ("c-types"))
   (:file "posn-stream" :depends-on ("utilities"))
   (:file "errors" :depends-on ("posn-stream"))
   (:file "lex" :depends-on ("posn-stream" "errors"))
   (:file "pset" :depends-on ("lex"))
   (:file "parse-c-types" :depends-on ("lex" "c-types" "tables"))
   (:file "class-defs" :depends-on ("parse-c-types"))
   (:file "cpl" :depends-on ("class-defs"))
   (:file "class-finalize" :depends-on ("class-defs" "cpl"))
   (:file "class-builder" :depends-on ("class-finalize" "pset"))
   (:file "class-layout" :depends-on ("class-defs"))
   (:file "module" :depends-on ("parse-c-types" "class-defs" "tables"))
   (:file "builtin" :depends-on ("module" "class-layout"))
   (:file "output" :depends-on ("module"))
   (:file "methods" :depends-on ("class-layout" "codegen" "output"))
   (:file "class-output" :depends-on ("builtin" "class-builder"
				      "methods" "output"))
   (:file "combination" :depends-on ("methods"))
   (:file "module-output" :depends-on ("combination" "class-output"))))

;;;----- That's all, folks --------------------------------------------------