[Gnu-arch-users] [OT] fixing make

[Tom Lord]

How about generalizing `make(1)' in the following ways:

1) Add dependencies on recipes.

   Suppose that I have:

        target:  dependencies ....
                recipe...

   I `make target', then change "recipe....".   `target'
   should no longer be considered up-to-date.   `make' will
   have to store a record of the recipes it used.


2) Add `rule' dependencies and computed rules.

   Let's suppose that I type `make target'.

   Make will want to know: "What is the rule for target?".

   To find that rule, if it wasn't provided in the input so far, it
   should recurse to build the target: `rule_of(target)'.  However, it
   should stop there: it should never try to build
   `rule_of(rule_of(target))' (see below).

   The recipe for `rule_of(target)' should be treated slightly
   specially:  the stdout of that recipe should be parsed and
   is expected to define a rule for `target'.


3) Add a special target, "RULES".

   All `rule_of(TARGET)' targets should implicitly depend on
   the target `RULES'.

   As with `rule_of(TARGET)', the stdout of the recipe
   for RULES should be parsed as further input input to make.


4) Add a feedback protocol for recipes.

   In a makefile, I should be able to write a special kind of
   rule-with-recipe using a special syntax such as:

        target::::  dependencies ....
                recipe text ....

   The firing of such recipes should only be permitted if `make'
   is invoked with the option:

        make --eval-server X

   where X is a descriptor number.

   When such a recipe is fired, instead of invoking $(SHELL),
   make writes to X a copy of "recipe text...." followed by a
   null byte.

   If the recipe is being invoked for its stdout, to be parsed 
   as further make rules, then it reads that stdout back from X,
   expecting it to be terminated by a null byte followed by a 
   decimal integer (the exit status of the recipe) followed by a 
   newline.

   (The details of this protocol are not important and were chosen
   just to illustrate the idea).



The upshot of this is that `make(1)' can then be a dependency graph
engine for any interpreter.   For example, my `Makefile' might say:



        RULES: scm-make-library-timestamp-file
                (construct-library "libfoo.a" (c-source-files))
                (install-headers (c-include-files))
                (install-library "libfoo.a")

expecting that I'll invoke:

        scm-make all

which will itself fork

        make --eval-server N all

(Interactions with recursive makes, parallel makes, and pattern rules
would need to be worked out, of course.)

-t