automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: Yacc outputs


From: Ralf Corsepius
Subject: Re: FYI: Yacc outputs
Date: 04 Jan 2002 16:25:58 +0100

Am Mit, 2002-01-02 um 15.48 schrieb Akim Demaille:
> >>>>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
> >> just a minor but important issue.
> Ralf> IMHO, this patch should not be applied, rsp. reverted.
> 
> Hi Ralf!
> 
> Ralf> *.output files are informative output files, comparable to
> Ralf> listings or files originating from using some "obscure verbosity
> Ralf> mode" options (Here: -v|--verbose) and not the actual/usable
> Ralf> product of invoking bison/yacc.
> 
> I disagree.  They _are_ part of the output, and it is because of
> Automake that people can't use the right options of Yacc/Bison to
> rename the output files.  Currently, the result is that you have
> y.output wandering around, and it is even worse if you happen to have
> several .y. 

How about using CLEANFILES?

> Which turns out to be exactly my case.
Then let me ask differently:

* What do _you_ use y.output for? 

Except for debugging and documentation purposes, I have never seen any
actual use of them and therefore fail to see why *.output should be
subject to any automake-activity.

* What is an *.output file?

It is not of any kind of source-code. I still fail to see why *.output
is any different from other arbitrary temporary files, e.g. like those
being produces by using ld -Map or gcc --save-temps. You would not try
to handle *.map rsp. *.i, *.s files generated by CC, wouldn't you?

> Without Automake,
> I would use bison --output, and there would be no such problem.
Frankly speaking, for me, automake's *.y/*.l fails to handle most cases
but very trivial ones.

I am inclinded to think that automake is trying to be clever wrt.
yacc/bison, but fails badly in non-trivial case.
If I knew a better approach than the one currently applied, I would have
tried to come up with a better one  ...

[I am using several *.yy/*.ll-files (ie. c++) in a single
source-directory, rely on using bison (not yacc), and flex++,
furthermore apply customized skeletons, ... To work-around these
problems, I am currently apply BUILT_SOURCES and manually written
.y[y]/.l[l] rules.

[Sorry if this may sound like ranting.]
 
Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]