From: Steven E. H. <seh...@ra...> - 2003-09-17 18:21:53
|
I'm trying to use mk:defsystem on a small project of mine, and have it working with a small set of constituent files. Now one of those files needs to make use of some of the PORT stuff (port:pipe-input, port:with-open-pipe) and I'd like to be able to express that dependency somehow. Seeing that PORT itself has a system definition (port.system), I tried to refer to that definition from one of my dependent file entries: (mk:defsystem ct :source-extension "lisp" :components ((:file "path-manip" :depends-on ("port")) ;; ... )) Of course, this doesn't work. I tried removing the quotes, using a longer path to the port.system file, adding #p"clocc:src;port;" to mk:*central-registry*, all to no avail. Is it possible to make one system definition file refer to another as a dependency? If not, what is the right way ensure that whenever I try to load my "ct" system above PORT will be loaded beforehand? Obviously, I can manually load port.system by hand, but I'm likely to forget that step in the future and I'd prefer some way to express the dependency in either a declarative or programmatic manner. Please help fix any misconceptions evident above. -- Steven E. Harris :: seh...@ra... Raytheon :: http://www.raytheon.com |
From: Edi W. <ed...@ag...> - 2003-09-17 18:35:55
|
On Wed, 17 Sep 2003 11:18:22 -0700, "Steven E. Harris" <seh...@ra...> wrote: > I'm trying to use mk:defsystem on a small project of mine, and have > it working with a small set of constituent files. Now one of those > files needs to make use of some of the PORT stuff (port:pipe-input, > port:with-open-pipe) and I'd like to be able to express that > dependency somehow. > > Seeing that PORT itself has a system definition (port.system), I > tried to refer to that definition from one of my dependent file > entries: > > (mk:defsystem ct > :source-extension "lisp" > :components ((:file "path-manip" > :depends-on ("port")) > ;; ... > )) This should work: (mk:defsystem ct :source-extension "lisp" :depends-on (#:port) :components ((:file "path-manip") ;; ... Make sure all your ".system" files are in places where MK:DEFSYSTEM can find them - see the variable MK:*CENTRAL-REGISTRY*. Edi. |
From: Steven E. H. <seh...@ra...> - 2003-09-17 19:22:27
|
Edi Weitz <ed...@ag...> writes: > Make sure all your ".system" files are in places where MK:DEFSYSTEM > can find them - see the variable MK:*CENTRAL-REGISTRY*. I've noticed that my ".system" files are all over the place, so MK:*CENTRAL-REGISTRY* has to grow in order to find each of them. Three observations make me think I'm doing something wrong. First, the name "central registry" suggests that maybe there's supposed to be one place where all these ".system" files live, not many places. Next, that mk:oos does not accept a path as an argument and only looks in MK:*CENTRAL-REGISTRY* forces one to keep adding entries to the registry. Finally, the source-pathname directive would be useless if the ".system" file is always in the same directory as the source it describes, for the path would then be obvious. Does this mean that one usually plucks the ".system" file out of a source bundle and puts in some special place (noted by MK:*CENTRAL-REGISTRY*) for convenient loading? If not, why must one "register" a path to the file, then give just the file basename to mk:oos, rather than just letting mk:oos accept the full path? -- Steven E. Harris :: seh...@ra... Raytheon :: http://www.raytheon.com |
From: Edi W. <ed...@ag...> - 2003-09-17 20:06:30
|
On Wed, 17 Sep 2003 12:18:59 -0700, "Steven E. Harris" <seh...@ra...> wrote: > Edi Weitz <ed...@ag...> writes: > > > Make sure all your ".system" files are in places where MK:DEFSYSTEM > > can find them - see the variable MK:*CENTRAL-REGISTRY*. > > I've noticed that my ".system" files are all over the place, so > MK:*CENTRAL-REGISTRY* has to grow in order to find each of > them. Three observations make me think I'm doing something > wrong. First, the name "central registry" suggests that maybe > there's supposed to be one place where all these ".system" files > live, not many places. Next, that mk:oos does not accept a path as > an argument and only looks in MK:*CENTRAL-REGISTRY* forces one to > keep adding entries to the registry. Finally, the source-pathname > directive would be useless if the ".system" file is always in the > same directory as the source it describes, for the path would then > be obvious. > > Does this mean that one usually plucks the ".system" file out of a > source bundle and puts in some special place (noted by > MK:*CENTRAL-REGISTRY*) for convenient loading? If not, why must one > "register" a path to the file, then give just the file basename to > mk:oos, rather than just letting mk:oos accept the full path? The usual way seems to be that the file in your central registry is a symbolic link to your "real" system definition. This has the effect that if you update your source directory the central registry will be updated as well. A technique you'll sometimes see is (defparameter *foo-base-directory* (make-pathname :name nil :type nil :version nil :defaults (parse-namestring *load-truename*))) (mk:defsystem #:foo :source-pathname *foo-base-directory* ;; ... This'll help you if you don't want to hard-code the source-pathname into your system definition and most (if not all) implementations[*] will do what you expect with respect to the symbolic link (although there's no guarantee for that in the ANSI spec) - at least on *nix-like systems. Edi. [*] For AllegroCL you'll need to have the latest patches loaded. |
From: Sam S. <sd...@gn...> - 2003-09-17 18:49:32
|
> * Steven E. Harris <fruneevf@enlgurba.pbz> [2003-09-17 11:18:22 -0700]: > > I'm trying to use mk:defsystem on a small project of mine, and have it > working with a small set of constituent files. Now one of those files > needs to make use of some of the PORT stuff (port:pipe-input, > port:with-open-pipe) and I'd like to be able to express that > dependency somehow. please see CLOCC/CLLIB - it uses PORT. cllib.system: (mk:add-registry-location (translate-logical-pathname "clocc:src;port;")) (mk:add-registry-location (translate-logical-pathname "clocc:src;tools;metering;")) (mk:defsystem cllib :source-pathname (translate-logical-pathname "clocc:src;cllib;") ;; :package :cllib :source-extension "lisp" :depends-on (port metering) :components ((:file "animals" :depends-on ("base" "string" "miscprint" "fileio" "closio" "symb")) (:file "autoload" :depends-on ("base" "fileio")) ...)) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> In C you can make mistakes, while in C++ you can also inherit them! |
From: Steven E. H. <seh...@ra...> - 2003-09-17 19:26:39
|
Sam Steingold <sd...@gn...> writes: > please see CLOCC/CLLIB - it uses PORT. Thanks. That's the kind of example I was looking for. > (mk:add-registry-location (translate-logical-pathname "clocc:src;port;")) > (mk:add-registry-location > (translate-logical-pathname "clocc:src;tools;metering;")) Ah, I was trying to do this in :initially-do with no effect. I forgot that these .system files are loaded as normal Lisp code, allowing one to include any other forms before the defsystem form. -- Steven E. Harris :: seh...@ra... Raytheon :: http://www.raytheon.com |