Re: CONS specs update?

[H. S. Teoh]

On Sun, Jun 27, 2004 at 03:35:47PM +0200, Pierre THIERRY wrote:
> > Strictly speaking, Lilypond processes the input .ly file to produce
> > either a .midi file or a .tex file.
> 
> OK, so it's completely separated from TeX, as far as Cons is concerned.

More or less, yes. Assuming that you treat "steps" separately as in
the C compiler (.c -> .s -> .o -> executable).


> > (How would you handle Java, btw? One .java file can be compiled into
> > multiple .class files depending on whether you have inner classes or
> > private classes defined.)
> 
> I aware of that issue because it was discussed sooner on the list, but I
> never worked with Java, so I don't know how this will be dealt with...

I think somebody (was it Steven?) mentioned that SCons implements this
by using a (crude) Java parser to quickly find out which .class files
will result from a given .java file.


> > Ideally, though, I'd prefer to treat them as separate steps. I don't
> > like the idea of a file modified in-place
> 
> It seems to me that it's a common case in the way people develop their
> own processors (I often do it with perl -i or Vim scripts, for example).
> We should not force people to change their work to be able to use Cons
> to build it, IMHO.
> 
> If using in-place processors has drawbacks (e.g. you loose the benefit
> of some Cons abilities), we could strongly encourage users of doing
> things antoher way, though.

It may not *completely* be a drawback... one idea that occurred to me
is that we can allow self-edges in the dependency graph, so that xyz.c
depends on itself via an in-place processor P. What this means is that
every time xyz.c is re-generated, P must be called on it again.

I'm not sure how to generalize this, but there might be a way to
specify that xyz.c must be re-scanned every time it's re-generated,
and there may be more than one scanner (e.g., if P1, P2, P3 must be
run, in that sequence, on the file to transform it to the desired
output).

(I realize that allowing self-references could potentially require
pathological code which may be a pain to test; this is why I suggested
that we should treat every step as having distinct input/output. It
does make things a lot easier to implement, and less prone to
pathological hard-to-debug cases.)


> > Now about result files... one reason I added Lilypond was to bring up
> > the issue of how we should handle steps that produce multiple targets
> 
> Yeah, I alos thought about this with TeX, that produce sometimes five or
> more targets (even if only one is very important for the user, the DVI).

I think we should treat all outputs as equally important, whether or
not the user cares about them. E.g., if the user wants CONS to clean
up all result files, it should know exactly which files have been
produced (and not leave .aux files lying around, for example).

This might also be important in cases where the final product depends
on targets produced by multiple paths from a previous step, e.g.:

     source1.xyz
     /        \
   target1    target2
    ...        ...
    |          |
   dep1       dep2
     \        /
      \      /
      product


> > In such cases, the dependency graph is not a tree, but a directed
> > (acyclic, hopefully) graph.
> 
> It's precisely why I used the term graph, where dependency tree is often
> used.
[...]

Yes, now that I think about it, it will probably be a graph, not a
tree, except in the simplest cases.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson