Open gasche opened 7 years ago
I think your plan is overly complex. Make the plugin, advertise it and deprecate -use-menhir
at the same time. Then kill the -use-menhir
in the subsequent version.
I agree with @dbuenzli, assuming the plugin still works in old ocamlbuild versions there is no downside to kicking these rules out of ocamlbuild.
I'm just adding my +1 in support of this wishlist item. Is it possible, with use-menhir or with a new alternative for it, to let the menhir invocation (on Ocamlbuild's command-line or in the _tags file) accept a string of menhir options that would be blindly passed to the menhir call, so that Menhir can keep on evolving without having to update Ocamlbuild's Menhir tags?
I'm a bit frustrated with the state of
menhir
support in ocamlbuild: there are many more options in the tool than there were when it was first implemented, and some of them require non-trivial choices from the build system point of view (in particular the way.messages
files are updated). I would be happy to provide a separate menhir plugin for ocamlbuild, but this seems to conflict with the-use-menhir
option that is supposed to already do the job.An idea I had not considered before is to indeed separate the plugin as a
menhir.ocamlbuild
plugin (distributed separately from menhir itself, and separately from ocamlbuild), but have hardcoded support for it inplugin.ml
that makes sure to link this plugin whenever-use-menhir
is passed, or give an error message if the plugin is not installed (we could also just do the minimal service of changing the command name tomenhir
, and emitting a warning instead of an error, to limit breakage among users that don't know about ocamlfind/opam). We would have two different codepaths for this linking depending on whether-use-ocamlfind
is used, but I think it should be fine.I think that this could achieve minimal disruption for most users, while simplifying and improving our relation with respect to Menhir-side changes.