From: <do...@co...> - 2000-02-25 23:21:31
|
>> Defconfiguration gives the downloader some flexibility which is nice >> (I'm not even convinced of that - see below) but not really necessary. >> For instance, the clocc standard could be that you run lisp, load >> defsystem (you have to start somewhere), set a global variable to your >> "clocc directory location", > >You just said it! "set a global variable". This is exactly the kind >of things I want to avoid. IMHO, this is akin to writing elaborated >"build.lisp" files which are very difficult to maintain. Have global variables been declared harmful while I wasn't looking? I wonder why such a wonderful language as lisp still supports them. Must be backward compatibility for dinosaurs like me. >> and from there on all locations are fixed. >> You download subsets of clocc source into standard places relative to >> the clocc directory. > >First of all, the CLOCC has a structure, other systems may have a >different one, not necessarily rooted. I believe this is the way mk defsystem (and all similar ones) already works. At the moment we're mainly trying to provide a reasonable way for people to use CLOCC. But I believe this will work fine for other systems too. >Secondly, how you set the "global variable" should - again IMHO - be >rephrased as "how do you set up your LOGICAL-PATHNAME-TRANSLATIONS?" I don't really care whether I set a global variable or set a single logical pathname translation. >It turns out that the only way to do it reliably and in a portable >way, is to write a SETF form somewhere, which must eventually be >manually edited by a downloader, installer. In this case it's likely that your init file requires defsystem and sets this variable. If your downloader runs from inside lisp then it uses this variable. I don't think it ever has to be changed until you decide to move your CLOCC directory. In my (imagined) version the actual content of the source files does not depend on this location at all so I don't think the installer or downloader has to edit any such thing. >Again, (and allow me to invoke the KMP God on this :) ), this editing >is something that should be kept and avoided is possible. How many >people like to edit other programmer's Makefiles? Not me. I am avoiding that editing. I require that the user set one variable, just as defsystem does (in fact it should be the same variable). It is you who require me to supply different location parameters for every subsystem, even though I want them all to be computed in a simple uniform way. >> If you deal with lots of systems I expect this will be the preferred >> solution anyway, since you don't really want to have to supply >> parameters for each system separately. > >Why not? This is what you do with autoconf. I believe you are talking about retrieving one system, not many subsystems on which it relies. In that case I type one command that includes one location in order to get one system. In the lisp case I want to do the same thing, even though the system I got actually depends on many other systems. >> What I'd like is that the >> downloader specifies >> - the location of his clocc directory > >DEFCONFIGURE is not just for the CLOCC. It is a general purpose tool. But >yes. Here is what you'd write > > (defconfiguration "CLOCC" ()) > >Then you'd have a CONF:SETUP method which can be called as > > (conf:setup 'clocc > :source-location "/the/clocc/src" > :library-location "/the/clocc/library") You imagine that I want to download all of CLOCC and perhaps build everything in it as one system. I imagine that I'd want to download one small subset at a time, that I'd never have more than a small fraction of the whole thing, and that what I want to build in one image is never more than a few top level systems (plus all that they require, of course). >You could also set up the keywords default in such a way to have the >system ask questions to the user. Alas, you could write a dialog form >thingy by parsing the defconfiguration form. No thanks. I want to compute all of this automatically. >> - one version of one system to download > > cvs -d ma...@cv...:/cvsroot/clocc -r XXX co > >> That causes all the appropriate versions of all the required systems >> to be downloaded into standard places relative to his clocc >> directory. > >Again. What you request is something different and more >complex. Pontentially you could "extend" DEFCONFIGURATION to deal with >versions, as well as you could "extend" DEFSYSTEM to do so. I believe that I already described such a scheme. Defsystem is extended very slightly to deal with versions. You then need a tool that understands the CLOCC CVS setup to read one system definition, figure out what versions of what files to retrieve, and download them. Then you use defsystem to recursively make all that is needed for the system you asked for. At that point I'm not sure defconfiguration gives you any benefit. >However, I need to see a good proposal in this sense. So far, the >only thing I can come up with is the comment I made some time ago >about replacing a back end. (?) doesn't ring a bell >> Then he runs lisp and loads the one configuration file (for the >> version he specified above) and that causes all the other >> configuration files (for required versions of required systems) to >> also be loaded. > >This is a good suggestion, however, one step at the time. > >> If you want to support different versions (which I do), I don't think >> that defsystem or even defconfiguration can be kept entirely ignorant >> of versions. > >I understand this. And I keep believing that the issues should be >kept as separate as possible. > >> Suppose I have downloaded two different versions of some >> system, s1.1.2 and s1.2.3. I can control which of these I configure >> by loading the configuration file for one or the other (which, after >> all, must be different files in different places). The problem is >> that these configuration files contain dependency data, and that data >> must be version aware. It's just not good enough for the s1.2.3 >> configuration file to contain >> (:required-system "S2") >> It has to specify which version of S2 is required. Otherwise how do >> you know which S2 configuration file to load? > >You can say > > (:special-translations :host "S2" ("*.*.*" "/s2-v-1.2.3/")) > (:required-system "S2" :system-location "S2:") > >I admit this is verbose. Syntax may be changed. My objection is not the syntax, but the fact that I have to say it at all for every subsystem. I want defsystem to know which version of s2 is required for each version of s1, and given that info I want to compute in some simple way where to find that version in my local CLOCC directory. The top level system I get might depend transitively on 50 other systems. I don't want to supply translations for each. >> Of course, I argued >> that the same is true for Defsystem. Perhaps the solution is for >> defconfiguration to load the defsystem file and get the dependency >> data from there. That data has to be there anyway, and surely it's >> better for it to be in only one place. > >Yes. I agree. But I still do not see a good design coming through. >Personally I would rather have this version tag at the configuration >level rather that at the defsystem level. Mostly because of the >separation of concerns between "building" and "version control". One way to do this would be to make the version tag part of the name of the system (and hence the directory where it's stored). That way defsystem could pretend there are no versions but just different systems, s1.1.2 and s1.2.3. But it's real important that you build and load the right s2 for a given s1. In that sense it is the business of defsystem. >> The one thing I see you have added that I think is needed is the idea >> of a binary location that depends on the target. > >Yes. This is needed. Somehow you can do that by passing a different >:library-loaction to the CONF:SETUP method, but it is not quite >satisfactory the way it is now. > >> I think it would be >> a good idea to standardize that using the environment package to >> provide the data from which to define a method to be added to >> defsystem. I really think this can be standardized so that nobody >> ever has to worry about it again. >> >> Aside: I always wonder whether different participants in these >> discussions just have incompatible models of how this is all going to >> work. It's always hard to be sure what another person has in mind. > >If we don't participate, it is difficult to be sure one way or the >other :) > Absolutely. |