Re: Building of generated parser files

Re: Building of generated parser files

[Niklas Hallqvist]

> Date: Fri, 22 Aug 1997 11:53:29 -0400
> From: Ian Lance Taylor <ian@cygnus.com>
> 
>    Date: Fri, 22 Aug 1997 09:09:35 +0200
>    From: Niklas Hallqvist <niklas@petra.appli.se>
> 
>    What about using --with-makeinfo and friends to configure?
> 
> A related possibility is the --enable-maintainer-mode that automake
> uses.  If you configure with --enable-maintainer-mode, then automake
> will automatically include Makefile rules that rebuild Makefile.in
> using automake and configure using autoconf.  If you configure without
> it, then the Makefile does not include those rules.
> 
> This can be easily and logically extended to support building files
> with makeinfo, bison, and other tools that are not included with the
> distribution.
> 
> It's possible that using a single option is too restrictive.  However,
> I think most people will not want to rebuild any of these files, and
> so the default will be correct.  I would guess that people who do want
> to rebuild tools will want to rebuild all of them, or will know how to
> cope if they don't have the necessary tool.


I think that --enable-maintainer-mode is a good idea, and simpler than
my initial proposal.  Should I go ahead and make a patch for egcs?
Should I take the general idea somewhere else for discussion if this
is a suitable thing to do in all GNU sw?  If so, where?  Does anybody
object to --enable-maintainer-mode instead of --with-* configure
arguments?

>    The other idea I have toyed with has been to add an option to CVS to
>    update modifications time on checked-out files to be that of the
>    particular revision (if it's not containing an edit).  I am more
>    scared of that though.
> 
> One possibility, which Jason Merrill suggested to me a while back, is
> to modify CVS to preserve timestamp ordering on check in and check
> out.  Not the actual timestamps, which I agree could be scary, but
> merely the ordering.

Interesting, but it seems non-trivial if cvs were to keep the ordering
globally (i.e. not per-directory) which might be needed if
cross-directory dependencies are existant.  Or don't you think so?

Niklas

970814: bootstrap failure for i386-pc-solaris2.5.1: _sys_siglistp dcl

[Jim Meyering]

collect2.c:217: conflicting types for `_sys_siglistp'

One fix is to define DONT_DECLARE_SYS_SIGLIST in
config/i386/xm-sysv4.h.  Better still would be to use autoconf
to test for this -- then remove the definitions from these files:

  config/xm-freebsd.h
  config/xm-linux.h
  config/alpha/xm-linux.h
  config/i386/xm-bsd386.h
  config/mips/xm-sysv4.h
  config/rs6000/xm-sysv4.h
  config/sparc/xm-sol2.h

Re: 970814: bootstrap failure for i386-pc-solaris2.5.1: _sys_siglistp dcl

[Jeffrey A Law]

  In message <yzqu3gh2hh3.fsf@boom.eng.ascend.com>you write:
  > collect2.c:217: conflicting types for `_sys_siglistp'
Yup.  Ran into it myself today while trying to get a 68k 4.4bsd
machine bootstrapped.

  > One fix is to define DONT_DECLARE_SYS_SIGLIST in
  > config/i386/xm-sysv4.h.  Better still would be to use autoconf
  > to test for this -- then remove the definitions from these files:
I'm going to look into having autoconf do it for us, but not
being an autoconf wiz, it might take a little while :-)

Jeff