[cap-talk] POLA for builds

[Bill Frantz]

toby.murray at comlab.ox.ac.uk (Toby Murray) on Wednesday, September 17, 2008 wrote:

>Most makefiles generate gcc commands that look something like
>
>gcc somefile.c -c -o somefile.o -DFLAGS -IINCLUDE -IINCLUDE -DFLAGS etc.
>etc.
>
>Here, we're explicitly providing each argument on the command line. An
>intelligent shell should be able to recognise these and construct gcc's
>namespace accordingly to contain only these things (plus its install
>endowment, of course).

I consider the makefile to be one of the programs you might want to
run under POLA.


shap at eros-os.com (Jonathan S. Shapiro) on Wednesday, September 17, 2008 wrote:

>Make is an undeniably nasty problem. Build environments are incredibly
>complex things -- especially at whole-system scales -- and *nobody* has
>a good answer for how to manage them. This may explain why a tool that
>was considered fairly icky in the early 1980s is still so widely used
>today in only modestly refined form...

While it is a nice design exercise to get minimum authority in a
POLA make system, fortunately it is not necessary in the real
world. (If it were possible I can see the truly horrible
requirement of required proprietary header files the programmer is
not permitted to read (but the compiler is).)


I must admit that I much preferred the system for building programs
used under VM/CMS. It was much simpler, and it seemed to do all the
things needed on that system.

It made heavy use of the ability to define "disks" (think
directories) as extensions of other disks. The semantics of this
facility are similar to the Unix "path" facility except that the
head disk may be read-write. If the build system wrote a file it
would be on the first disk, and shadow the visibility of files on
the extensions with the same name.

For testing a simple change, the compiler outputs on the extension
disks could be used directly, without each developer re-compiling
their sources. In the rarer case, when a system-wide header
changed, the developer needed to compiler everything which depended
on it, as with make. You could also "cheat" on the need to
re-compile by limiting your changes to extensions to the
system-wide structure. Then you only had to re-compile the code
that allocated, initialized, and released the structure.
Re-compiling the programs that only made use of the structure
didn't change there object code, and could be skipped.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032