www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/06/11/13:51:20

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3D060D90.71227138@phekda.freeserve.co.uk>
Date: Tue, 11 Jun 2002 15:47:44 +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 <djgpp-workers AT delorie DOT com>
Subject: automake 1.5, bison 1.35 and Fileutils 4.1 - y_tab.c vs. y.tab.c
Reply-To: djgpp-workers AT delorie DOT com

Hello.

I just updated a file in the Fileutils 4.1 sources - lib/getdate.y - and tried
to rebuild. It failed, because it was trying to rename a file y_tab.c to
getdate.c in lib/. bison had created a file called y.tab.c, as you might
expect, because I'm running with LFNs.

lib/Makefile has a fragment for generating C parsers:

.y.c:
        $(YACCCOMPILE) $< && mv y_tab.c $@
        if test -f y_tab.h; then \
          if cmp -s y_tab.h $*.h; then \
            rm -f y_tab.h; \
          else \
            mv y_tab.h $*.h; \
          fi; \
        fi

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 think the automake fragment above is broken in some cases, because 'bison
-y' only generates y_tab.c in an SFN environment. But the code above is used
unconditionally of SFN/LFN, I think.

I suggest that the DJGPP port of automake should force the file stem to be
y_tab, so that the above Makefile fragment will work in all cases.

(Note that this should not be an issue in the DJGPP port of Fileutils 4.1,
because I will include a manually generated file.)

Bye, Rich =]

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019