Re: Semantic error recovery

bill@amber.csd.harris.com (Bill Leonard) writes:
> We did look into using odin, but rejected it for two reasons:
> 1. It is not compatible with make input files.


This is true. For simple projects and simple Makefile's you might as well
stick with Make. For projects with Make problems, the degree of hackery
present in the Makefile's, especially with many of the "super-Make's", it
is not possible to mechanically extract what really is going on (which is
what makes these Makefile's so hard to read and maintain).


For most applications, an Odin description consists of a file (say
"demo.sm") containing a list of source files, e.g.:


      ../main.c
      subs/x.c,v
      subs/y.c,v
      foreign.o


and an Odinfile that contains the lines like:


demo ==
      demo.sm +debug :exe
lint ==
      demo.sm +debug :lint


which says that "demo" is an executable produced from "demo.sm" with
"debug" set. The default build rules know how to produce an executable
from a file list, and know that "debug" gets mapped to "-g" for the
debugger and the linker ("-gx" if you're on a pyramid). Similarly, "lint"
is the result of running lint on the demo.sm system.




> 2. The documentation was nearly impenetrable.


Currently, the only documentation provided with the distribution is the
reference manual, which approaches man-page terseness. The Bellcore
development conf. mgmt. group (I'm in Applied Research, but I work closely
with them) has produced a User's Guide, but it is currently tied up as
"Bellcore proprietary". If I can't get this changed, I'll write a public
domain version.


> I got the impression that
> writing (and reading) odin files was extremely complicated -- worse
> even than the most complicated make file! Perhaps my impression was
> mistaken, but the documentation helped me to that conclusion.


Odin files never get much more complicated than the example I described
above. Of course, inferring this from the reference manual is like trying
to write csh scripts using the csh man page. I will post to this
newsgroup when the User's Manual is available. I'd recommend that new
users wait until then, unless they like to learn to use tools from man
pages. If you are feeling adventurous, I'd advise looking at the
Odinfile's in the Odin distribution itself (the Odin system of course uses
Odin to build itself).


> One of the main reasons we looked into odin in the first place was that it
> allegedly supported "parallel builds". I could not find anything in the
> documentation to describe such support, let alone how to use it.


It appears in the "Variables" section in the reference manual. There are
two relevant variables, MaxBuilds and BuildHosts. MaxBuilds is an integer
indicating how many build steps should be fired off in parallel (default
is 2). BuildHosts is a colon separated list of host names, where LOCAL
refers to your local machine. For example, if


      BuildHosts = LOCAL:server1:LOCAL:server2:LOCAL:server1


then if there is just one build step, it will be done on the LOCAL
machine, if there are two parallel steps, they will be done on the LOCAL
machine and the host named "server1", if there are three, two will be done
on LOCAL and one will be done on server1, etc.


That's all there is to parallel builds: how many you want and where you
want them to run -- no warnings, proviso's, or /etc/rc modifications (:-).


By the way, anyone that has used the "Eli" compiler construction system,
distributed by Bill Waite at the Univ. of Colorado, is already an Odin
user, although you may not realize it (Eli is Odin with default build
rules for a variety of compiler construction tools).


Cheers,


Geoff
--
geoff@bellcore.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.