MakeDoDoc.tioga
Spreitzer, May 12, 1985 11:46:59 am PDT
MakeDO
CEDAR 6.0 — FOR INTERNAL XEROX USE ONLY
MakeDo
Mike Spreitzer
© Copyright 1985 Xerox Corporation. All rights reserved.
Abstract: MakeDo automatically determines dependencies between files, and can issue whatever commands are necessary to bring derived files up to date.
Created by: Mike Spreitzer
Maintained by: Mike Spreitzer <Spreitzer.pa>
Keywords: Make, Dependency, Consistency, Derive, File, DF File, Command, Compile, Bind, Order, Sequence
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
1. MakeDo
name MakeDo
syntax
MakeDo  list of: fileName, -arggedSwitch fileName, or -assumeAllInconsistent 
(where arggedSwitch is one of: gr, gm, dr, dm, md, or mn)
Do whatever is necessary to produce up-to-date versions of the named files (possibly with limits on what is allowed to be rederived).
MakeCommandList  list of: fileName, -arggedSwitch fileName, or -assumeAllInconsistent 
(where arggedSwitch is one of: gr, gm, dr, dm, md, or mn)
Lists the commands that MakeDo would execute, under some vanilla assumptions about the results of those executions (execution of any one command may affect later decisions).
Explain list of files
Explain why the last invocation of MakeDo did what it did about producing the indicated files.
description
MakeDo executes whatever commands are necessary to produce up-to-date versions of given files. For instance, it will run the compiler and binder, on the right files, in the right order. You have the option of delimiting what MakeDo is allowed to cause to be changed. Excercizing this option gives you added safety and error reporting.
Each argument to MakeDo is a name, or a name preceeded by a switch, or a bare switch. Bare names are taken to be goals. Here is what the switches mean:
gr: Following is a DF-file name. Take the files in it marked as verify-roots (i.e., preceeded by a "+") to be goals.
gm: Following is a DF-file name. Take all the modifiable files in it (i.e., ones that might be stored if you did an SModel) to be goals.
dr: Following is a DF-file name. Take the files in it marked as verify-roots to be goals. Add to the delimited set of what MakeDo may change all of the modifiable files in the DF-file.
dm: Following is a DF-file name. Take all the modifiable files in it to be goals.
md: Following is a DF-file name. Add to the delimited set of what MakeDo may change all of the modifiable files in the DF-file.
mn: Following is a file name. Add it to the delimited set of what MakeDo may change.
assumeAllInconsistent: Assume that every derived file is inconsistent with its sources.
If one of the switches dr, dm, md, or mn is used, the set of things MakeDo may cause to be changed is delimited to what was explicitly asked for, plus, of course, the goals. Otherwise, what MakeDo may change is undelimited --- it may change anything.
MakeDo has a general registration mechanism, whereby it can be made aware of any command that produces some set of files from some other set of files. This general mechanism leaves it up to the clients to determine when some derived files are inconsistent with their source files. The compiler and binder registration uses version stamps (correct), not create dates (incorrect), to determine when it is necessary to recompile or rebind.
Currently, the compiler, the binder, and Lupine (the RPC stubs generator) are registered with MakeDo. The Parser Generator System (PGS) may come at some time in the future.
The procedures registered for the compiler and binder have a hack that allows compilation or binding switches to be specified. To specify the switches for module Foo, in a file named Foo.BCD.Switches put the switch string, including the introductory character.
The procedures registered for Lupine also have a hack for specifying additional parameters. For translating Foo.BCD, in the file Foo.LupineSwitches, put on the first non-empty line the additional lupine commands (e.g., InlineDispatcherStubs[FALSE] LineLength[60]).
examples
Suppose you have a package. It has a public interface (Foo), a private interface (FooPrivate, which references Foo), two implementation modules (FooImplA and FooImplB, both of which reference FooPrivate), and a configuration (FooPackage, which references FooImplA and FooImplB). After any sequence of compiling, binding, and editing, the command
% MakeDo FooPackage.BCD (the ".BCD" is optional, so far)
will do whatever compiles and binds are necessary to produce an up-to-date version of FooPackage.BCD. For instance, if everything was up-to-date, then you edited FooImplA, then issued the MakeDo command, MakeDo would compile FooImplA and then (if the compile was successful) bind FooPackage. If you were working in subdirectory Foo, with a FooPackage.BCD.Switches that contained
/c~s
it might look like this:
% Compile []<>Foo>FooImplA.Mesa
Compiling: FooImplA/-g . . . . . . no errors.
End of compilation
% Bind /c~s FooPackage
Binding: FooPackage
. . . . 0 errors
End of binding
If you have a Foo.DF that follows all the usual conventions, a good way to invoke MakeDo is
% MakeDo -dr Foo.DF
warnings
The compiler and binder registrations currently take a shortcut for explanations. If things change between when they are consulted, and when explanation is asked for, the explanations may be bogus. But, things are not likely to change in that interval, if you ask for explanations right after a MakeDo (it says right here!).
stop/undo
Click the STOP! button in the commander.
implementation
MakeDoPackage.Config, in MakeDo.DF
contact
Spreitzer