libcdecl doesn't use the readline module at all, but libtool happily
pulls it in as a dependency. Handle library dependencies manually to
avoid this problem.
Nick Bowler [Wed, 21 Sep 2011 23:11:39 +0000 (19:11 -0400)]
Fix build with NLS disabled.
When NLS is disabled, we should not install any .mo files but we still
need to distribute the .po files. However, ALL_LINGUAS was not being
set in this case, so the POFILES was not set if NLS is disabled, causing
a distcheck failure.
Also fix a build error in this case due to a missing #include.
Nick Bowler [Wed, 21 Sep 2011 23:12:52 +0000 (19:12 -0400)]
Include config.h in scan.l.
This is required for things to work. Unfortunately, %top{...} appears
to be the only bit where config.h can be put in a flex scanner, as
headers are included before the first %{...} block is output. Thus, the
include ends up in the scan.h header file. Nevertheless, this should
not be a problem since config.h only defines macros.
Nick Bowler [Wed, 21 Sep 2011 04:51:17 +0000 (00:51 -0400)]
Rewrite Gnulib symbols to be in libcdecl's namespace.
The gnulib symbols are not properly prefixed for libcdecl internal
symbols (e.g. cdecl__blah). This *will* cause problems when statically
linking against both libcdecl and another library that uses the same
gnulib modules.
Unfortunately, there's no simple way to determine what symbols need
prefixing without compiling all the gnulib objects. The results can't
be distributed either, because they depend on the configuration. So,
limited to simple tools and portable make rules, we hack together a
"new" config.h at build time that defines object-like macros to rewrite
the symbols, carefully ensuring that header dependencies are correct.
Nick Bowler [Mon, 19 Sep 2011 03:01:18 +0000 (23:01 -0400)]
Eliminate use of BUILT_SOURCES from Gnulib.
As with recursive make, BUILT_SOURCES is harmful because of inadequate
dependency information. We can achieve a similar effect with by using
order-only dependencies: These force the headers to be up-to-date
before anything that might require them is built: but rebuilds are only
triggered based on the accurate dependency information generated by the
normal mechanisms.
Unfortunately, order-only dependencies are a GNU make feature, so we use
a hack which should fall back to ordinary dependencies on other make
implementations. The worst effect of using ordinary dependencies will
be that files might be needlessly rebuilt when a header changes.
Nick Bowler [Thu, 15 Sep 2011 01:10:19 +0000 (21:10 -0400)]
Enable i18n in Bison.
This makes us require library initialization. To avoid requiring an
explicit call, we implicitly initialize the library when it is first
required. Bring in Gnulib's threading library to do this in a
thread-safe manner when available.
Nick Bowler [Sun, 11 Sep 2011 23:28:57 +0000 (19:28 -0400)]
Use .Va instead of .Fa in man pages when appropriate.
".Va" means "variable name", which is more appropriate than "function
argument" for variables. Nevertheless, they're probably typeset the
same way, anyway.
Nick Bowler [Sun, 11 Sep 2011 23:28:35 +0000 (19:28 -0400)]
Re-word description of nonterminals in man page.
There's no reason to assume that "function arguments" are typeset with
an underline. So re-word that sentence to avoid directly stating
typographical conventions by using an example instead.
Nick Bowler [Sun, 10 Jul 2011 16:25:37 +0000 (12:25 -0400)]
Split up interactive/noninteractive loops.
Readline isn't well suited for non-interactive loops since it tends to
print stuff to standard output. So use two loops: a readline-based one
and a getline-based one.
Nick Bowler [Thu, 7 Jul 2011 00:39:47 +0000 (20:39 -0400)]
Don't gratuitously reject inline specifiers.
We actually do support functions now, so we need to handle inline.
Turns out the last user of the old output routines (the code that
prints "inline") didn't actually work properly, so port it over to
the new interface.
Nick Bowler [Wed, 6 Jul 2011 02:43:42 +0000 (22:43 -0400)]
Kill the "horizontal" declarator chain.
The "next" pointer in declarators is used in exactly one place: the list
of declarators of a declaration. Move this chain to the toplevel so
that we get a list of declarations instead: now every struct cdecl has
exatly one declarator.
This helps eliminate the nasty hack in "explain" to print multiple
declarators.
Nick Bowler [Mon, 4 Jul 2011 22:11:51 +0000 (18:11 -0400)]
Add support for empty declarators.
This allows the parser to recognize type names which are required for
function prototypes, as well as actual declarations. This also makes it
easy to let the user ask for an explanation of types. For instance:
Nick Bowler [Sat, 25 Jun 2011 13:45:16 +0000 (09:45 -0400)]
Add support for array declarators.
Currently there is a (I think quite reasonable) restriction that the
array length either be unspecified, a positive integer constant, an
identifier, or *.
Nick Bowler [Sat, 25 Jun 2011 12:52:17 +0000 (08:52 -0400)]
Restrict the contexts in which typedef names can appear.
This should resolve a rather nasty ambiguity in the C grammar:
[declaration] -> [declaration-specifiers] ;
-> [type-specifier] [declaration-specifiers] ;
-> int [declaration-specifiers] ;
-> int [type-specifier] ;
-> int [typedef-name] ;
-> int [identifier] ;
-> int x ;
versus
[declaration] -> [declaration-specifiers] [init-declarator-list] ;
-> [type-specifier] [init-declarator-list] ;
-> int [init-declarator-list] ;
-> int [init-declarator] ;
-> int [declarator] ;
-> int [direct-declarator] ;
-> int [identifier] ;
-> int x ;
The standard resolves this ambiguity by having a constraint that is not
part of the context-free grammar. This ambiguity gets really nasty with
things like int f (x); -- is it a declaration of x with two type
specifiers or a declaration of f (a function with one parameter) with
with one type specifier?
A side-effect of this change is that the parser will now reject
declarations without any type specifiers at all, which probably makes
the error messages a bit less informative.
Nick Bowler [Sat, 25 Jun 2011 00:26:25 +0000 (20:26 -0400)]
Fix VPATH builds from git.
In such builds, C source files (that are normally distributed) get
generated, which means they end up in the build tree. Building them
subsequently fails because headers (in the source tree) are not found.
Nick Bowler [Thu, 23 Jun 2011 00:30:52 +0000 (20:30 -0400)]
Kill typemap_is_valid.
Just do the check when building the map in the first place. This
enables more useful error messages, too: the case where there are no
type specifiers at all is certainly worth diagnosing separately from
other kinds of nonsense.