[Omake] omake support for Menhir?
Francois Pottier
Francois.Pottier at inria.fr
Wed Jun 14 01:51:47 PDT 2006
Hello,
On Tue, Jun 13, 2006 at 06:07:34PM -0700, Jason Hickey wrote:
>
> To use it, you add this line to your OMakefile, the rest is automatic.
>
> MENHIR_ENABLED = true
>
> # Also define extra Menhir options if you like
> MENHIR_FLAGS += ...
This is great. I have one remark, though: because Menhir supports
multiple-file grammar specifications, it would be nice if things
could optionally be slightly less automatic. Users sometimes need
to specify that a.{ml,mli} is built from a.mly *and* b.mly. My
original omake rules looked like this:
# Menhir: multiple file projects.
MenhirMulti(target, sources, options) =
TARGETS = $(file $(target).ml $(target).mli)
SOURCES = $(file $(sources))
$(TARGETS): $(SOURCES)
$(MENHIR) --ocamlc "$(OCAMLC)" $(PGFLAGS) --base $(target) $(options) $(SOURCES)
.SCANNER: $(TARGETS): $(SOURCES)
WrapScanner($(MENHIR) --ocamldep "$(OCAMLDEP)" --depend --base $(target) $(options) $(SOURCES))
# Menhir: single file projects.
MenhirMono(target, options) =
MenhirMulti($(target), $(target).mly, $(options))
# Menhir: automatic single file projects.
# This causes every .mly file to be viewed as a single file project.
MenhirAuto() =
foreach (target, $(glob *.mly))
MenhirMono($(removesuffix $(target)), $(EMPTY))
The details are not important, but the idea is that the user was supposed
to call one of MenhirAuto, MenhirMono, or MenhirMulti.
It would be good for the behavior that you have implemented to remain the
default (all .mly files considered stand-alone, options read from
MENHIR_FLAGS) and to allow overriding this behavior by calling something like
MenhirMulti above.
> The unfortunate thing is that it relies on a custom ocamldep.
I'll do some local lobbying for the -modules option. As far as I have
understood, it does not change any existing functionality, only add a
new output format, so there is no reason not to accept it.
> It seems that menhir looks at the output of ocamldep (I assume to fix it).
Yes, currently ocamldep outputs a dependency line that looks like this:
foo.cmo: foo.cmi bar.cmi quux.cmi
(where foo.mly is the grammar file) and Menhir replaces that with
foo.ml foo.mli: bar.cmi quux.cmi
(note that the targets are different and the dependency over foo.cmi
is dropped).
Is this something that becomes entirely unnecessary with your ocamldep
patch?
> - When I use --ocamldep "ocamldep -I ../foo" I get this error.
> Error: failed to make sense of ocamldep's output.
> Is it legal to depend on files in other directories?
It should be legal. But Menhir was being too picky. This will be
fixed in the next release.
> - With the new dependency model, ocamldep -modules does not print
> make-style output. For accuracy, it would be nice to use
> the new ocamldep with Menhir, but this will cause an error.
>
> Would it be reasonable to have something like --rawocamldep,
> so that Menhir prints the output from ocamldep verbatim?
Certainly, that would be the way to go, if indeed no postprocessing
by Menhir is necessary.
Thank you very much. I'm looking forward to this whole thing working
smoothly.
--
François Pottier
Francois.Pottier at inria.fr
http://cristal.inria.fr/~fpottier/
More information about the Omake
mailing list