This commit factorizes the way the menhir flags for unused tokens
is defined. It also brings the comments explaining why tokens are
unused above the definition of the unused_tokens variable.
This change should be a refactoring no-op.
Before, a DEPFLAGS variable existed in some makefiles to contain
include directories to be passed to ocamldep invocations, but no
support for easily adding command-line flags to ocamldep was available
(invocations would systematically use -slash, which was duplicated
across callsites).
With this PR, a new DEPINCLUDES variable contains the include
directories, and DEPFLAGS is repurposed to contain other command-line
flags for the tool -- currently "slash".
This fixes a problematic issue to a wrong Makefile.menhir that
was supposed to have been fixed by f10736b9e6, but actually was not.
Apologies for the flawed commits and for the noise.
(This is the sort of horror sorry when the `mv`, which intended to move
temporary Menhir-produced files to `boot/`, was wrongly placed (by myself)
on the call to copy the runtime files from Menhir's installation directory
into `boot/`. As a result, running 'promote-menhir' would break your Menhir
install...)
François Pottier reported that, on his mac machine,
"make promote-menhir; make world" fails: it seemed
that parsing/parser.ml, after being produced as a temporary
file by the promote-menhir target, is not refreshed using
the `parsing/parser.ml: boot/menhir/parser.ml` rule from
Makefile (which does the MenhirLib->CamlinternalMenhirlib renaming).
The issue comes down to the fact that while boot/menhir/parser.ml
is always younger than the parsing/parser.ml produced by promote,
the time difference is very small (parser.ml is copied in boot/
immediately after production), and macos doesn't record creation times
with enough precision to notice it.
This PR removes the temporary parsing/parser.ml created by Menhir
in the promote-menhir rule, so that this file is not seen anymore
by 'make world', and has to be properly reproduced from boot/.
François Pottier reported that, on his mac machine,
"make promote-menhir; make world" fails: it seemed
that parsing/parser.ml, after being produced as a temporary
file by the promote-menhir target, is not refreshed using
the `parsing/parser.ml: boot/menhir/parser.ml` rule from
Makefile (which does the MenhirLib->CamlinternalMenhirlib renaming).
The issue comes down to the fact that while boot/menhir/parser.ml
is always younger than the parsing/parser.ml produced by promote,
the time difference is very small (parser.ml is copied in boot/
immediately after production), and macos doesn't record creation times
with enough precision to notice it.
This PR removes the temporary parsing/parser.ml created by Menhir
in the promote-menhir rule, so that this file is not seen anymore
by 'make world', and has to be properly reproduced from boot/.
François Pottier reported that, on his mac machine,
"make promote-menhir; make world" fails: it seemed
that parsing/parser.ml, after being produced as a temporary
file by the promote-menhir target, is not refreshed using
the `parsing/parser.ml: boot/menhir/parser.ml` rule from
Makefile (which does the MenhirLib->CamlinternalMenhirlib renaming).
The issue comes down to the fact that while boot/menhir/parser.ml
is always younger than the parsing/parser.ml produced by promote,
the time difference is very small (parser.ml is copied in boot/
immediately after production), and macos doesn't record creation times
with enough precision to notice it.
This PR removes the temporary parsing/parser.ml created by Menhir
in the promote-menhir rule, so that this file is not seen anymore
by 'make world', and has to be properly reproduced from boot/.
The large diff in boot/menhir/parser_menhir.ml comes from the fact
that the token list is now included in it, instead of being merely
a reference to the yacc parsers' Parser.token type.
The goal of this change is to avoid conflicts encountered by
compiler-libs users that would also use their own MenhirLib runtime
for their own parsers.
I first tried to implement a solution to this module-name-conflict
issue using module aliases and -open, but this proven too fragile and
too difficult to get right.
The yacc parser already uses its --strict flag, which turns grammar
conflicts into build errors so that they are noticed. Menhir uses
a more extensive semantics for the --strict flag, as it turns into
errors grammar warnings that have no yacc counterpart, in particular
unused precedence levels. We have to fix more mistakes, which I guess
is good news.
Sébastien Hinderer
Gabriel Scherer
François Pottier