> Delivery-Date: Sat, 26 Feb 2000 00:18:03 +0100
> Date: Fri, 25 Feb 2000 15:19:04 -0800
> From: donc@... (Don Cohen)
> CC: clocc-devel@...
> Sender: clocc-devel-admin@...
> X-Mailman-Version: 1.1
> Precedence: bulk
> List-Id: <clocc-devel.lists.sourceforge.net>
> X-BeenThere: clocc-devel@...
> >> 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.
Global variables are fine. Structured linguistic extensions are better.
> >> 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.
I am trying to abstract from the CLOCC.
> >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.
I argue that you are actually doing both. When you set 'the'
variable, you are actually setting the location of your
code. I.e. most likely you have one file somewhere that does
(defvar *the-beast-location* "/where/Dante/went/")
(setf (logical-pathname-translations "INFERNO")
DEFCONFIGURATION is a standardized syntax wrapper for these
practices. This is what DEFSYSTEM is for a different task.
> >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.
I want my 'init' file to contain one "standardized" DEFCONFIGURATION form.
> 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.
I concede this as a potential problem. As a matter of fact in one early
version of DEFCONFIGURATION I toyed with the idea of providing a
CONF:CONFIGURE method as well as a CONF:SETUP one. The first one
would generate a "cached" "configuration instance" with "configured"
locations. It may be worthwhile to re-explore the idea.
> >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.
I am not requiring you to supply the parameters. I give you the
ability to supply them or not and a way to make sure that your system
has many of the required pieces in place before you start
compiling/loading it. I also give you some independence from the
underlying DEFSYSTEM implementation.
> >> 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,
You need to define what a "subset" of the CLOCC (or of any other
thing) is. If it is a "system" defined with a DEFSYSTEM utility, all
you will have to do is to load the ".system" file and take it from
> 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).
This is what you can do using DEFCONFIGURATION and DEFSYSTEM in
tandem. I admit, that there is *some* overlap between
DEFCONFIGURATION and MK:DEFSYTEM, but AFAIK (please correct me if I am
wrong) this overlap varies greatly for the different DEFSYSTEM
> >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.
This is/should be/will be under control of the DEFCONFIGURATION form writer.
> >> - one version of one system to download
> > cvs -d marcoxa@... -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.
Fine. You can easily add a :version keywork in the components forms.
> 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
Again. as I said, this amouns to providing a plug in for the DEFSYSTEM
file system substrate. As I said, I have no clear idea about how to
go ahead and do that.
> 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.
It does because you set separatedly your nedded logical pathname
translations. It may also help if you use a non MK:DEFSYSTEM
> >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
See my comment above.
> >> 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.
You want a versioned file system. Sorry, you can't have that under
your vanilla Unix/Linux or Windows or Mac.
Again, I am all for it. But I do not want a CVS/CLOCC only solution.
Suppose we want to develop such a thing at the MK:DEFSYSTEM level.
(Note that I still assume you want a DEFCONFIGURATION somehow)
A MK:DESFYSTEM relies on (or describes) a directory forest, plus some
"extraneous" dependencies, mostly in the form of :system clauses. You
want to add some info about the "version" of the defined system. This
version info is also "attached" to the :system clauses (all
""-enclosed terms are vaguely defined).
Now you have the following choice for a sensible implementation:
1 - rely on an underlying version control system (VCS)
a - you provide support only for CVS
b - you provide an interface that makes it easy to add a different
Case (a) may be simple to use, unfortunately, CVS allows you to
start from a void, by issuing a 'cvs checkout' into an empty
directory, hence you immediately have to face the problem of
ensuring that your MK:DEFSYSTEM spec is consistent with the CVS
view of the directory tree/forest. This problem is not particular
to CVS, PRCS also has similar problems.
Anyway, suppose you want to go this way. You immediately need to
parse CVS status information to make sure that your "system" spec
is in line with the version you specify. This is doable, but it
is not immediate.
Once you have solved those problems, you still need to make sure
that when you do a
(mk:load-system 'zut :version (mk:version 2 3 4))
(I just made up the MK:VERSION specifier based of the CL:BYTE
function) eventually you ensure that you have the the appropriate
version at hand (maybe by doing first a checkout using the
underlying CVS). (BTW, this is independent of where your
LOGICAL-PATHNAME-TRANSLATIONS are set).
Case (b) is rather complicated. What is the a good abstraction of
the underlying VCS operations available? How do you solve the
problem of "reading" the VCS information and comparing it to the
version info in the MK:DEFSYSTEM utility?
2 - Write a MK:DEFSYSTEM integrated VCS in CL.
It is a very hard problem.
> >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).
This is what LOGICAL-PATHNAMES are there for.
> 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.
Yes and no. Of course you could munge the system name, but that is
rather ugly and it may violate the VCS conventions.
AFAIK, the directory-avec-version-name is usually an artifact of the
distribution construction (or configuration management) procedure.
> make dist VERSION=3.14
that you issue when you are ready to create a tarball of the system.
Anyway, all of this is good. Let's just move one step at the time.
Eventually we'll get there.
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26