Re: Bison
Hi, On 12/01/11 06:24, John Calcote wrote: On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? Hi Russell - try the techniques listed here: http://www.mail-archive.com/help-bison@gnu.org/msg01897.html Hi J.C, It's close to what i'm looking for, but not complete enough. I'm not good at autoconf stuff. Why is descriptor 5 used? ac_compile_yacc='$CC -c $CFLAGS $CPPFLAGS $ac_cv_prog_yacc_root.c 5' If you're using automake-1.10+, that should provide a YACC variable override: ./configure YACC=/my/yacc ... I've attached my m4 macro for testing whether $YACC is really bison or yacc, not just relying on the program name. automake also provides a helper script 'ylwrap' to deal with yacc/bison compilations and do some file renaming. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/ dnl @synopsis HACKT_ARG_VAR_YACC dnl dnl Enables YACC as a configurable variable. dnl This usually picks up bison by default if found, dnl but can be manually overridden. dnl Note: automake-1.10+ already provides YACC variable dnl This macro now runs some test to detect certain traits dnl of the parser generator. dnl dnl @category InstalledPackages dnl @version 2008-03-14 dnl @author David Fang fang...@users.sourceforge.net dnl @license AllPermissive dnl AC_DEFUN([HACKT_ARG_VAR_YACC], [AC_REQUIRE([AC_PROG_YACC]) AC_ARG_VAR(YACC, [parser generator, requires LALR(1), such as yacc/bison]) cat conftest.y ACEOF %token FIRST_TOK %token LAST_TOK %start top %% top: FIRST_TOK LAST_TOK %% ACEOF dnl fake cache variable should probably use different name prefix ac_cv_prog_yacc_root=y.tab ac_compile_yacc='$CC -c $CFLAGS $CPPFLAGS $ac_cv_prog_yacc_root.c 5' dnl test 1: find the enumeral value of the first token if $YACC -d -t -v conftest.y eval $ac_compile_yacc then if ! test -f $ac_cv_prog_yacc_root.c then AC_MSG_ERROR([$YACC does not produce $ac_cv_prog_yacc_root.c.]) fi if ! test -f $ac_cv_prog_yacc_root.h then AC_MSG_ERROR([$YACC does not produce $ac_cv_prog_yacc_root.h.]) fi YACC_FIRST_TOKEN_ENUM=`grep ^#define.*FIRST_TOK $ac_cv_prog_yacc_root.h | cut -d\ -f3` fi AC_SUBST(YACC_FIRST_TOKEN_ENUM) dnl test 2: if yacc, get the version string of the skeleton dnl eventually pass this into YACC_VERSION yacc_skeleton_version=`grep skeleton $ac_cv_prog_yacc_root.c | \ cut -d\ -f2 | sed 's/[$]//g'` dnl test 3: find name of preprocessor symbol for MAXTOK dnl is YYMAXTOKEN for yacc, YYMAXUTOK for bison dnl test 4: what is the real underlying parser generator? ac_for_real_yacc= if grep -q YYBISON $ac_cv_prog_yacc_root.c ; then ac_for_real_yacc=bison AC_DEFINE(USING_BISON, 1, [Define to 1 if we're using bison.]) elif grep -q YYBYACC $ac_cv_prog_yacc_root.c ; then ac_for_real_yacc=byacc AC_DEFINE(USING_BYACC, 1, [Define to 1 if we're using byacc.]) else dnl is YACC ac_for_real_yacc=yacc AC_DEFINE(USING_YACC, 1, [Define to 1 if we're using yacc.]) fi AC_MSG_NOTICE(parser generator is really $ac_for_real_yacc) AM_CONDITIONAL(HAVE_BISON, test $ac_for_real_yacc = bison) AM_CONDITIONAL(HAVE_BYACC, test $ac_for_real_yacc = byacc) AM_CONDITIONAL(HAVE_YACC, test $ac_for_real_yacc = yacc) dnl test 5: directive support case $ac_for_real_yacc in dnl ( bison ) YACC_PURE_PARSER=%pure_parser ;; dnl ( *) YACC_PURE_PARSER= ;; esac AC_SUBST(YACC_PURE_PARSER) dnl test 6: version string case $ac_for_real_yacc in dnl ( bison ) YACC_VERSION=`$YACC --version 21 | head -n 1` [BISON_VERSION=`echo x$YACC_VERSION | sed 's/[^.0-9]//g'`] AC_MSG_NOTICE([found bison version $BISON_VERSION.]) ;; dnl ( *) YACC_VERSION=$yacc_skeleton_version ;; esac AC_SUBST(YACC_VERSION) dnl TODO: run more tests dnl clean up files: y.tab.c y.tab.h y.output rm -f y.* dnl for use in Makefile ])dnl ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison
Russell Shaw wrote: How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? Is this really an autoconf question? Seems like something the build system should handle, not the configuration system. If you're using automake, look into BUILT_SOURCES: http://www.gnu.org/software/hello/manual/automake/Built-Sources-Example.html cheers, -tom ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison
On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? Hi Russell - try the techniques listed here: http://www.mail-archive.com/help-bison@gnu.org/msg01897.html Regards, John ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison
On 12/01/11 06:24, John Calcote wrote: On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? Hi Russell - try the techniques listed here: http://www.mail-archive.com/help-bison@gnu.org/msg01897.html Hi J.C, It's close to what i'm looking for, but not complete enough. I'm not good at autoconf stuff. Why is descriptor 5 used? ac_compile_yacc='$CC -c $CFLAGS $CPPFLAGS $ac_cv_prog_yacc_root.c 5' ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison and autotest
Hello Tys, * tys lefering wrote on Sat, Jan 23, 2010 at 07:43:53PM CET: GNU bison is using autotest with 'make maintainer-check' and that works fine. at failed test lines appear like: ./regression.at:941: $CXX $CXXFLAGS $CPPFLAGS $LDFLAGS -o dancer dancer.cc $LIBS is it possible to have the $CXX etc. expanded to 'g++' in the output or needs that change to autotest? The default (--verbose) output displays the AT_CHECK command line as it is before passing it to the shell. That's by intention, because it might provide helpful clues as well (say, you misspelled CXXFLAGS). To also see the expanded command line, use the --trace aka. -x flag: ./testsuite -v -d -x 239 242 or, if you're running from 'make', probably something like make maintainer-check TESTSUITEFLAGS=-v -d -x 239 242 (-d avoids overwriting your testsuite.log file). Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison and flex target
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey
This works for me. But i have a problem it works only if i use 1
yacc/lex. But when i move to add in multiple lexer's etc not too sure
how to make this work..
I see stuff on the gdb hack to redefine all the variables but not too
sure how this is meant to work. I am not a total guru with bison and
flex yet so sorry if this is basic :)
- -Phil
Philip Herron wrote:
Ralf Wildenhues wrote:
Hello Philip,
* Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST:
I am not sure if this is autoconf or automake.
If you use Automake, then this is an Automake question. :-)
I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate
programs for the configure.ac. But how do you go about adding them as
build targets so:
yacc -d foo.yy
lex foo.l
are run to get y.tab.{c,h} and lex.yy.c
Try something like
bin_PROGRAMS = foo
foo_SOURCES = foo.yy bar.l
If you are not using Automake, well, you can use @LEX@ and @LEXLIB@ in
your Makefile.in, as well as @y...@.
Cheers,
Ralf
Hey
Thanks for that i am using automake but all i did was just specify my c
files to compile.
I'll give a go and just add my lex and yacc stuff in like that i didn't
think it would work as easy as that. I'll try it tomorrow
Thanks
-Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkncpHQACgkQAhcOgIaQQ2FfiQCggSwNRrF12jfLeCq5P9r6NIa8
ohAAnAukPEqbv7QWUFgzBAy5lANIJP9/
=JO7G
-END PGP SIGNATURE-
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison and flex target
Hello Philip, please don't top-post, thank you. Also, what do you think about moving to the automake list, where this topic fits better? Followup set. * Philip Herron wrote on Wed, Apr 08, 2009 at 03:20:00PM CEST: Ralf Wildenhues wrote: * Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST: I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate programs for the configure.ac. But how do you go about adding them as build targets so: Try something like bin_PROGRAMS = foo foo_SOURCES = foo.yy bar.l This works for me. But i have a problem it works only if i use 1 yacc/lex. But when i move to add in multiple lexer's etc not too sure how to make this work.. Can you show what you have so far, and how it's failing? Ideally as a small example. I see that there is currently no test in the Automake test suite that uses the #define renaming. We should change that and add a full working test. Contributions welcome. I see stuff on the gdb hack to redefine all the variables but not too sure how this is meant to work. I am not a total guru with bison and flex yet so sorry if this is basic :) I am not a total guru with bison and flex either, so I'd appreciate a working example here, too. Also to ensure that Automake doesn't regress here, or promise something in the manual that won't work anyway. Thanks! Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison and flex target
Hello Philip,
* Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST:
I am not sure if this is autoconf or automake.
If you use Automake, then this is an Automake question. :-)
I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate
programs for the configure.ac. But how do you go about adding them as
build targets so:
yacc -d foo.yy
lex foo.l
are run to get y.tab.{c,h} and lex.yy.c
Try something like
bin_PROGRAMS = foo
foo_SOURCES = foo.yy bar.l
If you are not using Automake, well, you can use @LEX@ and @LEXLIB@ in
your Makefile.in, as well as @y...@.
Cheers,
Ralf
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison and flex target
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
Hello Philip,
* Philip Herron wrote on Fri, Apr 03, 2009 at 02:51:50PM CEST:
I am not sure if this is autoconf or automake.
If you use Automake, then this is an Automake question. :-)
I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate
programs for the configure.ac. But how do you go about adding them as
build targets so:
yacc -d foo.yy
lex foo.l
are run to get y.tab.{c,h} and lex.yy.c
Try something like
bin_PROGRAMS = foo
foo_SOURCES = foo.yy bar.l
If you are not using Automake, well, you can use @LEX@ and @LEXLIB@ in
your Makefile.in, as well as @y...@.
Cheers,
Ralf
Hey
Thanks for that i am using automake but all i did was just specify my c
files to compile.
I'll give a go and just add my lex and yacc stuff in like that i didn't
think it would work as easy as that. I'll try it tomorrow
Thanks
- -Phil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknWgqoACgkQAhcOgIaQQ2GsUwCfQSoFPGuziDKnt6wgEK7d5gU5
JaYAniIWqWKx/QKd8LA6AbFZda5R5WuN
=OyzE
-END PGP SIGNATURE-
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison configuration is incorrect
On 10/24/06, Paulo J. Matos [EMAIL PROTECTED] wrote: For some unknown reason when I use AC_PROG_YACC, I get when I run configure: checking for bison... byacc -d The reason is not unknown anymore and it was my fault which copied a bunch of bash configuration to my .bashrc and one of the lines was setting YACC flag to byacc -y. Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison 2.3
Akim == Akim Demaille [EMAIL PROTECTED] writes: OK. I've suggested splitting the autotest test suite before. Let's look at that idea again sometime later (one file per test, and source them for execution from the main test suite script), it's bound to give both execution time improvements and portability improvements. I would like to emphasize that having a single file was a goal: I meant the test suite to be easy to copy, to install, etc. I would have loved to have split tests though, so that you could easily re-run a specific test in its own testsuite.dir/111/ directory. The problem was to make independent split tests without using functions. Now that we can have functions, that's much more doable. I once thought about using shar to build testsuite as a single program that would expand into more independent scripts, and a master to drive them. It would also ease the creation of a common store where some tests could share material. I never had time to do it. Maybe, if the idea looks sound, someone will... :)
Re: Bison 2.3
OK. I've suggested splitting the autotest test suite before. Let's look at that idea again sometime later (one file per test, and source them for execution from the main test suite script), it's bound to give both execution time improvements and portability improvements. Using functions should already seriously reduce the problem, Autotest is even more repetitive that Autoconf is.
Re: Bison 2.3
* H.Merijn Brand wrote on Wed, Jun 07, 2006 at 09:28:16PM CEST: On Wed, 7 Jun 2006 20:38:38 +0200, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Paul Eggert wrote on Wed, Jun 07, 2006 at 08:27:17PM CEST: H.Merijn Brand [EMAIL PROTECTED] writes: It's a long-known fact that the AIX /bin/sh is painfully slow due to this. The GCC install manual has recommended setting CONFIG_SHELL to bash for years. And if one does not have bash? Well, if /bin/sh aka /bin/ksh is the only usable shell, there isn't much choice. I don't know if the Bourne shell /bin/bsh is any more usable in practice, but I'd seriously doubt it. BTW, does the flooding lead to /tmp being full, /bin/sh running out of file descriptors, running out of file names, or did you just kill it at one point while it was still running? My personal notes tell me both out of file descriptors, amd file system full happened. Since then, I just kill the test suite once I see enough passes and no fails OK. I've suggested splitting the autotest test suite before. Let's look at that idea again sometime later (one file per test, and source them for execution from the main test suite script), it's bound to give both execution time improvements and portability improvements. Cheers, Ralf
Re: bison generated files
Hi, On Tue, May 23, 2006 at 07:51:01PM -0400, Bob Rossi wrote: Does 'make dist' automatically include them in the distro though? supposing you are using Automake, yes. Stepan ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison generated files
Does 'make dist' automatically include them in the distro though? supposing you are using Automake, yes. And if you don't use Automake, the answer is `maybe'. groff doesn't use Automake, but it's `make dist' *does* ensure that all bison and texinfo generated files go into the tarball; (none of these are kept in CVS). Regards, Keith. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison generated files
On Mon, May 22, 2006 at 02:13:26PM -0400, Bob Rossi wrote: Hi, Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do not need bison installed if they do not change the bison grammar files. If so, how do I do this? Ping. Bob Rossi ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison generated files
Bob Rossi [EMAIL PROTECTED] writes: Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do not need bison installed if they do not change the bison grammar files. I usually don't check them in myself. People who build from CVS are expected to have up-to-date tools. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison generated files
On Tue, May 23, 2006 at 04:48:56PM -0700, Paul Eggert wrote: Bob Rossi [EMAIL PROTECTED] writes: Does anyone know if bison generated files typically get checked into the source repository, and build system the same way flex generated files are? That way, other developers or users do not need bison installed if they do not change the bison grammar files. I usually don't check them in myself. People who build from CVS are expected to have up-to-date tools. Does 'make dist' automatically include them in the distro though? Thanks, Bob Rossi ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison generated files
Hi Bob, * Bob Rossi wrote on Wed, May 24, 2006 at 01:51:01AM CEST: Does 'make dist' automatically include them in the distro though? Yes. info Automake Yacc and Lex Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: bison-1.29c 'configure' problems on Solaris 8.
Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary As far as shell functions are concerned, it seems to me that Gary m4sh could provide shell function wrapper macros which expand to Gary a function/function call if that is supported by the shell, or Gary else an inline function if not... Something which creates satellites executables (small sh scripts instead of functions) when functions are not supported? I often thought about that. Gary Then again, perhaps I am the only one who finds symbolic Gary debugging of shell scripts to be useful ;-) I think it's a cute idea. Never used it yet though.
Re: bison-1.29c 'configure' problems on Solaris 8.
On Fri, Oct 19, 2001 at 06:00:38PM +0200, Akim Demaille wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary As far as shell functions are concerned, it seems to me that Gary m4sh could provide shell function wrapper macros which expand to Gary a function/function call if that is supported by the shell, or Gary else an inline function if not... Something which creates satellites executables (small sh scripts instead of functions) when functions are not supported? I often thought about that. I am sure it would work, and perhaps it would encourage people with broken shells to install bash... but somehow adding a couple of hundred little scripts to the libtool run time fills me with fear! Gary Then again, perhaps I am the only one who finds symbolic Gary debugging of shell scripts to be useful ;-) I think it's a cute idea. Never used it yet though. I had ambitions to integrate it into ddd (which already handles perl for example). Unfortunately bash's implementation of the DEBUG trap is not powerful enough to support full debugging written in shell, so I plan to add some better support for symbolic debugging directly into bash one day. Cheers. Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: bison-1.29c 'configure' problems on Solaris 8.
Paul == Paul Eggert [EMAIL PROTECTED] writes: From: Akim Demaille [EMAIL PROTECTED] Date: 04 Oct 2001 17:31:18 +0200 First let's find a portable LINENO, *then* move to another shell. Paul But the attempt to find a portable LINENO is not cost-free. Paul It is broken now, and it will take time to fix it, and this is Paul time that will be almost entirely wasted in practice once we Paul execute configure with a portable shell. So am I understanding that LINENO is a POSIX feature? The current implementation in CVS Autoconf might be broken, but really, I fail to understand what makes you fear the LINENO stuff that much. Why do you say it is broken? What is the *current* problem? Raja says it works fine on Solaris 8. I'm referring to CVS Autoconf, of course. Paul These days, almost nobody runs on systems that lack portable Paul shells. I wouldn't spend a lot of time worrying about these Paul rare, ancient systems, particularly as the LINENO feature is not Paul essential for proper operation of configure. I definitely agree!!! That's exactly what I'm doing! I'm moving at getting more and more new shell features into Autoconf, but I can't see that LINENO stuff being that bad. If you do think we should drop it, and I'm not strictly against that decision, but very reluctant, then I would really like to have the opinion of the comaintainers. People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too (i.e., Autotest scripts, M4sh-AdHoC scripts and so on).
Re: bison-1.29c 'configure' problems on Solaris 8.
On Fri, Oct 05, 2001 at 10:56:04AM +0200, Akim Demaille wrote: People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too (i.e., Autotest scripts, M4sh-AdHoC scripts and so on). There might be problems with re-execing to get a shell that has a feature that you want... invariably, the shell that you use will be *lacking* a feature that someone else wants. I wrote a section about finding a shell that supports functions for the Goat Book: http://sources.redhat.com/autobook/autobook/autobook_214.html#SEC214 But when I tried to add this to libtool, it conflicted with libtool's requirement for a shell that doesn;t mangle backslash escapes. ISTR that there were several systems that couldn;t provide a shell that supplied both :-( In this instance I could have fallen back on using libtool's --fallback-echo, but it felt as though this was moving in the wrong direction... As far as shell functions are concerned, it seems to me that m4sh could provide shell function wrapper macros which expand to a function/function call if that is supported by the shell, or else an inline function if not... although `trap DEBUG' doesn't work very well for functions, so my bashdb debugger will be considerably less effective if shell functions come into common use for configury. Then again, perhaps I am the only one who finds symbolic debugging of shell scripts to be useful ;-) Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: bison-1.29c 'configure' problems on Solaris 8.
Hi, Akim! People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? *And*, keep in mind the decision involves M4sh too (i.e., Autotest scripts, M4sh-AdHoC scripts and so on). Fine with me as long as the testsuite doesn't break. I understand that it doesn't. -- Regards, Pavel Roskin
Re: bison-1.29c 'configure' problems on Solaris 8.
From: Akim Demaille [EMAIL PROTECTED] Date: 05 Oct 2001 10:56:04 +0200 So am I understanding that LINENO is a POSIX feature? Yes. The current implementation in CVS Autoconf might be broken, but really, I fail to understand what makes you fear the LINENO stuff that much. Why do you say it is broken? What is the *current* problem? The latest problem is what happens when you type control-C when you are generating configure.lineno. My guess is that there will be more problems. Raja says it works fine on Solaris 8. I'm referring to CVS Autoconf, of course. After I checked in a regenerated 'configure', I think it probably works on Solaris 8 if your environment is OK. But I suspect we'll run into more problems later, as people run it with different environment variables, or on different hosts. People, the question is: If we look for a reasonable shell and re-exec configure once we found one, are you OK with keeping $LINENO used in configure, even if the shell does not treat $LINENO specially? I don't quite understand the question as worded. Here's how I would word the question: Suppose we change configure so that, if invoked with a shell that does not support LINENO, it first looks for a shell that supports LINENO and re-executes configure with that shell. This should avoid the LINENO problem on all major operating systems shipped in the last seven years or so. (SunOS 4.1.4, the last major holdout, shipped in November 1994.) If we do this, is it still worth the aggravation of maintaining code to substitute LINENO ourselves, for older hosts like SunOS 4.1.4 that have no shell that supports LINENO? The advantage of substituting for LINENO is that configure failures will have nice-looking line numbers even on older hosts. This advantage applies only when configure fails. The disadvantage is that the LINENO-substituting code does not work in all cases now, will hardly ever be exercised, and will probably continue to have bugs indefinitely.
