[Omake] scanning of .mly files

[Benjamin Pierce]

> The problem is that ocamldep ignores .mll and .mly files.  IMHO,  
> this is a bug (see http://caml.inria.fr/mantis/view.php?id=3725 ).   
> In the meantime, you must explicitly block scanning until the  
> corresponding .ml files are generated.
>
>    # Block scanning globally until these files are generated
>    OCamlGeneratedFiles(parser.ml parser.mli lexer.ml)
>
>    # Block scanning only in this directory
>    LocalOCamlGeneratedFiles(parser.ml parser.mli lexer.ml)
>
> I'm not sure how to define a way to do this generically.  Maybe  
> something like the following would specify, "If a foo.ml is in the  
> project, and foo.mly exists, build foo.ml before scanning."
>
>    .PREBUILD: %.ml: %.mly

I guess the fly in the ointment here is that "foo.ml" may *not* be in  
the project because it is to be generated automatically (and gets  
tidied away by "make clean").

I'd prefer something more eager/aggressive: I wish we could interpret

        .PREBUILD: %.ml: %.mly

as "If foo.mly [n.b.] is in the project, then generate foo.ml before  
scanning other things."

But I worry that both of these approaches may lead to difficulties,  
since it is not very clear exactly what "before scanning" means.   
E.g., in the case of Harmony, the file parser.mly is itself generated  
from yet another file, parser.srcy, using a little OCaml program that  
must, in turn, get built before it can be used...

> Hmm, I'm not sure if you are using -k or such.  The build order is  
> "nondetermistic".  Basically, the leaves of the build tree define a  
> "ready-queue" of targets that can be built, and their order in the  
> ready-queue is arbitrary.  However, if you are not using -k, and  
> you start from a fresh tree, it _should_ be deterministic.
>
> As far as debugging a lack of dependencies, it is hard:(

Yes.  A good readable way of displaying all the dependencies that  
*do* exist, and why, would go a long way in the right direction, though.

     - B