[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Serious problem with automake and bison
From: |
Anon |
Subject: |
Serious problem with automake and bison |
Date: |
Sat, 01 Sep 2007 21:34:48 -0400 |
Hello,
I am using automake 1.10
I made a bison file called parse.y with options
%glr-parser
%locations
%pure-parser
to generate a glr parser. Unfortunately, within the generated file
parse.c there was an
#include y.tab.h
which is obviously *wrong* and really should really be: '#include
parse.h'.
To give context this is the beginning of the generated file with the
unfortunate #include in it.
/* C GLR parser skeleton written by Paul Hilfinger. */
/* Identify Bison output. */
#define YYBISON 1
/* Bison version. */
#define YYBISON_VERSION "2.3"
/* Skeleton name. */
#define YYSKELETON_NAME "glr.c"
/* Pure parsers. */
#define YYPURE 1
/* Using locations. */
#define YYLSP_NEEDED 1
#include "y.tab.h"
/* Enabling traces. */
#ifndef YYDEBUG
# define YYDEBUG 0
#endif
With automake 1.10 it seems that ylwrap is used to rename the original
files and do some other things, because when I do a 'make parse.c', I
get the following output:
/bin/sh ../ylwrap parse.y y.tab.c parse.c y.tab.h parse.h y.output
parse.output -- bison -y -d
With this in mind, I inserted the following crude hack in ylwrap to
replace the offending #include
#############I ADDED THIS#############
base=`basename $target .c`
mv $target $target.tmp
sed -e 's,y.tab.h,'$base'.h,g' $target.tmp > $target
##################################
which does the job for now but isn't pleasant. I would rate this bug as
severe since I don't know of an elegant workaround.
- Serious problem with automake and bison,
Anon <=