[Top][All Lists]

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

Re: Location of bison.simple

From: Akim Demaille
Subject: Re: Location of bison.simple
Date: 20 May 2002 10:24:18 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

>>>>> "Paul" == Paul Hilfinger <address@hidden> writes:

Paul> The current sources use an m4 command like this:

Paul> running: .../gm4 -I .../install/share/bison m4sugar/m4sugar.m4
Paul> /tmp/bsnCHaqGD bison.simple

Paul> The problem is that if bison.simple happens to be in the CURRENT
Paul> directory (admittedly unlikely, except for developers), 

I've always considered this as a bug in M4 :(  I planed to fix GNU M4
(so that it also looks at the -I locations is reversed order), and
thought 1.5 could be released before Bison.  But, please, fix this.

Paul> that version of the bison.simple is what you get, ignoring the
Paul> installed version, AND ignoring the setting of BISON_PKGDATADIR
Paul> (which is undocumented).  (Setting BISON_SIMPLE (which IS
Paul> documented) doesn't work in any case, as it seems to have been
Paul> removed.)

This is because I'm ambivalent wrt BISON_SIMPLE.  I'm in favor of
removing it, especially because now directories are more important.
Something that we must implement soon in Bison is -I support.

Paul> I have this intuition that I am observing some intermediate
Paul> stage of evolution to a new spec.  What might it be?

I'm in favor of BISON_SIMPLE support removal, and actually not
documenting BISON_PKGDATADIR support either: it is there only because
currently we have no -I support and we, developpers, need to be able
to change the path though.

So, feel free to pass bison.simple with absolute path (but bare in
mind that this is still ``wrong'' since you can still pick the wrong
m4sugar), and to remove any reference to envvar in the documentation.

--include/-I is becoming an urgent need.  Does any one know a good
-I/--include + directory walks implementation that we could steal?  I
know that of a2ps, but it was written ages ago, and I'm pretty sure
there must be something better somewhere.

reply via email to

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