Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3D0E45A1.C2941FB7@phekda.freeserve.co.uk>
Date:	Mon, 17 Jun 2002 21:25:05 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: automake 1.5, bison 1.35 and Fileutils 4.1 - y_tab.c vs. y.tab.c
References:	<3D060D90 DOT 71227138 AT phekda DOT freeserve DOT co DOT uk> <20020617143234 DOT GA27267 AT kendall DOT sfbr DOT org>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

JT Williams wrote:
> 
> -: I looked at the automake installed files and it appears to come from
> -: share/automake/am/yacc.am. But in yacc.am, the names are
> -: y.tab.<whatever>. I haven't found what does changes '.' to '_' yet.
> 
> I don't know if there is a canonical solution to this problem,
> but for my own stuff I use a fragment like this in Makefile.cfg:
> 
> ifneq ($(COMSPEC),)
>         DOT = _
>         EXEEXT = .exe
>         SEP = ;
> else
>         DOT = .
>         EXEEXT =
>         SEP = :
> endif
> 
> after which I make reference only to y$(DOT)tab.h, foo$(EXEEXT), etc.

The problem with that is that the DJGPP ports of bison 1.28 and later will
generate y.tab.c if long filenames are available, otherwise y_tab.c. In both
these cases COMSPEC should be set, so this Makefile fragment is broken.

My suggestion is that automake-generated Makefiles should always force bison
to generate the y_tab.c form. You may also wish to do that to your Makefiles.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -