Re: patterns

[Johan Holmberg]

On Fri, 25 Oct 2002 address@hidden wrote:
>
> Thanks for the example... So from what you're saying, the only
> disadvantage _here_ with cons' approach versus make's approach is that
> I have to specify each source file and how it is built, right?
>

Yes.

> If there are multiple steps to the process, do I have to describe each
> one individually for each file? For instance, suppose I have a general
> macro preprocessor which I want to invoke on all my source files
> before building them. The unprocessed files end with ".in". In make, I
> would write
>
> % :: %.in
>         my_macro_processor <$< >$@
>
> With this Makefile and a file "foo.c.in", I could run "make foo" to
> build an executable; with a dvips rule as mentioned above, and latex
> rule, and a file "doc.tex.in", I could also run "make doc.ps" to
> generate a postscript file. Make would combine my macro rules with
> each other and with its own implicit rules, and apply them
> automatically to generate the desired target file. How would you write
> the corresponding cons script?
>

One way to  describe the difference between make (with it's pattern
rules) and Cons, is like this:

Both make and Cons basically works in two steps:

    1) build a depedency graph based on the content of the
       Makefile/Construct file

    2) "walk" the depedency graph and build files that are
       "out of date".

But the pattern-rules in make break this pattern.
make "discovers" new nodes in the dependency graph while "walking"
the graph. What nodes to add depends on what files exists in the
file-system. Cons has nothing corresponding to this "late discovery"
of new dependency nodes (if we ignore include-files for the moment).

So to accomplish the same dependency graph in Cons as the one you
got in make, you have to add the right nodes during step 1) above.

      #------------------------------
      $e = cons->new();

      @in_files = ("foo.c", "bar.txt", "frotz.tex");

      for my $file (@in_files) {
          $e->Command($file, "$file.in", "my_macro_processor %< %>");
      }
      #------------------------------

But nothing stops your from getting the list of "in-files" from the
filesystem in the Constrict file (after all, the file is a Perl
script):

      #------------------------------
      $e = cons->new();

      @in_files = map { s/\.in$//; $_ } glob("*.in");


      for my $file (@in_files) {
          $e->Command($file, "$file.in", "my_macro_processor %< %>");
      }
      #------------------------------


I don't know if this is the best way to explain the difference
between make and Cons, but it's the way *I* think about this myself.
It was also what I meant when I wrote in my earlier mail:

>
> A Construct instead explicitly tells Cons what there is to build.
> But since you have a real programming language at your disposal
> the difference isn't so big. [...]
>

And if you have the long chain of dependencies, like:

      "foo.tex.in" -->  "foo.tex" --> "foo.dvi" --> "foo.ps"

you have to "enter" all steps explicitly in the dependency graph.
One way would be to take advantage of Perl and write a
function/method

      process_tex_in_2_ps_in_three_steps("foo");

How you solve this in your Construct file, is *programming problem*,
ie. the best way to structure the solution is up to you ...

I hope my attempt to explain things was understandable.

Of course, it's just my view ...
(or $0.02 as you say over there).

/Johan Holmberg