+2008-11-15 Akim Demaille <demaille@gostai.com>
+
+ Move sc_tight_scope into maint.mk.
+ It does not work, and I don't know how it was supposed to work: it seems
+ to be looking for sources in the build tree. I just moved it at a better
+ place, fixing it is still required.
+
+ * src/local.mk (echo): Remove.
+ (sc_tight_scope): Move to...
+ * maint.mk: here.
+
+2008-11-15 Akim Demaille <demaille@gostai.com>
+
+ Regen.
+ * src/parse-gram.h, src/parse-gram.h: Regen.
+
+2008-11-15 Akim Demaille <demaille@gostai.com>
+
+ Remove src/Makefile.am.
+ * src/Makefile.am: Rename as...
+ * src/local.mk: this.
+ Prefix all the paths with src/.
+ (AUTOMAKE_OPTIONS): Build object files in the sub dirs.
+ (AM_CPPFLAGS): Find find in builddir/src.
+ (YACC): Move the flags into...
+ (AM_YFLAGS): here.
+ * maint.mk (sc_tight_scope): Disable.
+ It used to bounce to the version in src/Makefile.am which is now
+ part of this very Makefile.
+ * Makefile.am, configure.ac: Adjust.
+ * src/scan-code-c.c, src/scan-code.l: We can no longer rely on
+ include "..." to find files "here": we are no longer in src/, so
+ qualify the includes with src/.
+ * doc/Makefile.am (PREPATH): No longer include the top_builddir
+ prefix.
+ (.x.1): Adjust to be able to create src/foo from the top level
+ Makefile, instead of going bounce to src/Makefile the creation of
+ foo.
+
2008-11-15 Akim Demaille <demaille@gostai.com>
Remove useless variable.
Remove examples/local.mk.
examples/calc++/Makefile.am might be interesting to keep as is, since
it is an example in itself.
-
+
* examples/Makefile.am: Rename as...
* examples/local.mk: this.
Adjust.
Remove build-aux/Makefile.am.
Recursive Makefiles are really way too slow, let's get rid of some of
them.
-
+
* build-aux/Makefile.am: Rename as...
* build-aux/local.mk: this.
Adjust paths.
Using template buys us nothing, and makes it uselessly complex to
construct a symbol. Besides, it could not be generalized to other
languages, while make_FOO would work in C/Java etc.
-
+
* data/lalr1.cc (b4_symbol_): New.
(b4_symbol): Use it.
(b4_symbol_constructor_declaration_)
generated files. Because of name clashes, it is good to have such a
prefix such as TOK_ that protects from names such as EOF, FILE etc.
But it clutters the grammar itself.
-
+
* data/bison.m4 (token.prefix): Empty by default.
* data/c.m4 (b4_token_enum, b4_token_define): Use it.
* data/lalr1.cc (b4_symbol): Ditto.
symbol::token.
This is allows the user to get the type of a token return by
yylex.
-
+
* data/lalr1.cc (symbol::token): New.
(yytoknum_): Define when %define lex_symbol, independently of
%debug.
Define make_symbol in the header.
To reach good performances these functions should be inlined (yet this is
to measure precisely). To this end they must be available to the caller.
-
+
* data/lalr1.cc (b4_symbol_constructor_definition_): Qualify
location_type with the class name.
Since will now be output in the header, declare "inline".
The constructors are called by the make_symbol functions, which a
forthcoming patch will move elsewhere. Hence the interest of putting them
together.
-
+
The stack_symbol_type does not need to be moved, it is used only by the
parser.
-
+
* data/lalr1.cc: Move symbol_type and symbol_base_type
constructors into...
(b4_symbol_constructor_definitions): here.
Make it easier to move the definition of yytranslate_.
Forthcoming changes will make it possible to use yytranslate_
from outside the parser implementation file.
-
+
* data/lalr1.cc (b4_yytranslate_definition): New.
Use it.
goes against the stronger typing I am trying to have with the new
lex interface which return a symbol_type. So in this case, feed
yytranslate_ with a token_type.
-
+
* data/lalr1.cc (yytranslate_): When in %define lex-symbol,
expect a token_type.
The union used to compute the size of the variant used to iterate over the
type of all the symbols, with a lot of redundancy. Now iterate over the
lists of symbols having the same type-name.
-
+
* data/lalr1.cc (b4_char_sizeof_): New.
(b4_char_sizeof): Use it.
Adjust to be called with a list of numbers instead of a single
Symbols may have several string representations, for instance if they
have an alias. What I call its "id" is a string that can be used as
an identifier. May not exist.
-
+
Currently the symbols which have the "tag_is_id" flag set are those that
don't have an alias. Look harder for the id.
-
+
* src/output.c (is_identifier): Move to...
* src/symtab.c (is_identifier): here.
* src/symtab.h, src/symtab.c (symbol_id_get): New.
not work well in C++ (unless the parameter also appears as an argument,
which is not acceptable), hence the use of a function instead of a
constructor.
-
+
* data/lalr1.cc (b4_symbol_constructor_declaration_)
(b4_symbol_constructor_declarations)
(b4_symbol_constructor_specialization_)