Re: Building of generated parser files

Re: Building of generated parser files

[Fergus Henderson]

Niklas Hallqvist <niklas@petra.appli.se> writes:
> 
>    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?
> 
> One appropriate place for further discussion might be
> configure@cygnus.com, which is a general GNU list for configuration
> issues.
> 
> Personally, I like --enable-maintainer-mode, and I think we should go
> with it.

Why not have both?  `--enable-maintainer-mode' would then just be
an alias for `--with-this --with-that --with-the-other'.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

egcs-ss-970821 - Coldfire code generation problem

[Joel Sherrill]

While compiling egcs-ss-970821 to target m68k-rtems, I encountered the
following problem building newlib:

/usr1/rtems/work/build-m68k-tools/gcc/xgcc
-B/usr1/rtems/work/build-m68k-tools/gcc/ -idirafter
/usr1/rtems/work/build-m68k-tools/m68k-rtems/newlib/targ-include
-idirafter /usr1/rtems/work/src/newlib/libc/include -nostdinc -O2 -g
-m5200  -O2 -DHAVE_GETTIMEOFDAY -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DMISSING_SYSCALL_NAMES -fno-builtin
-I/usr1/rtems/work/build-m68k-tools/m68k-rtems/newlib/./targ-include
-I/usr1/rtems/work/src/newlib/./libc/include -c
../../../../../../src/newlib/libc/stdio/vfscanf.c
/tmp/cca28012.s: Assembler messages:
/tmp/cca28012.s:623: Error: operands mismatch -- statement `or.l 
#272,-646(%a6)' ignored
/tmp/cca28012.s:1180: Error: operands mismatch -- statement `or.l
#704,-646(%a6)' ignored
/tmp/cca28012.s:1526: Error: operands mismatch -- statement `or.l
#960,-646(%a6)' ignored
/tmp/cca28012.s:1648: Error: operands mismatch -- statement `or.l
#192,-646(%a6)' ignored

--joel

Re: Building of generated parser files

[John Carr]

> 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.

I think it is important to restore the file timestamps lost when
moving from the gcc2 snapshots to the egcs snapshots.  Making CVS
update the file times on checkout is probably the best way to do this.

Re: Building of generated parser files

[Niklas Hallqvist]

> Date: Sat, 23 Aug 1997 12:26:21 -0400 (EDT)
> From: Ian Lance Taylor <ian@cygnus.com>
> 
>    Date: Sat, 23 Aug 1997 14:44:54 +0200
>    From: Niklas Hallqvist <niklas@petra.appli.se>
> 
>    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?
> 
> One appropriate place for further discussion might be
> configure@cygnus.com, which is a general GNU list for configuration
> issues.

OK I have just subscribed to it.  I see there has already been
cross-posted traffic there.

> Personally, I like --enable-maintainer-mode, and I think we should go
> with it.

Yes, I've started working on a new more complete patch for egcs.  I
like to get a consensus on a few issues on configure@cygnus.com before
I submit it, though.

Niklas

Re: Building of generated parser files

[Ian Lance Taylor]

   Date: Sat, 23 Aug 1997 19:02:57 -0400
   From: Richard Stallman <rms@gnu.ai.mit.edu>

   What do people propose for --enable-maintainer-mode to mean?

--enable-maintainer-mode is currently being used by automake.

If --enable-maintainer-mode is used when you configure, it means that
you will get a Makefile which will automatically rebuild Makefile.in
from Makefile.am using automake, and automatically rebuild configure
from configure.in using autoconf, among other automatic dependencies.

If you do not use --enable-maintainer-mode, then you will have to
explicitly rebuild Makefile.in, configure.in, and other files by hand.

The intention is that people who configure normally, without
--enable-maintainer-mode, will not have to worry about the timestamp
of their configure.in vs. their configure, and so forth.  This matters
because most people will not have autoconf or automake installed.

I believe this is a correct use of a --enable option for configure.

Of course, it's best if the timestamps are correct, so the rebuild
doesn't happen anyhow.  However, as packages travel through the net,
timestamps often get messed up.

We are discussing making the gcc configure script support
--enable-maintainer-mode to not rebuild the info files from the
texinfo files.

Ian

Re: Building of generated parser files

[Richard Henderson]

> Ok I dived into doing the stuff I proposed some hours ago.  To me it
> seems like a way to go generally in GNU sw.  I enclose a patch below
> that shows the ideas.  I only handle the --with-makeinfo switch as
> this is more of a proof of concept than anything else.  Similar
> patches can be made for --with-bison, --with-texi2dvi, etc.

Why not just detect which programs are available and enable
all found?  I presume it is not the fractional extra build time
that is the reason for wanting to conditionalize this.

And possibly use --enable-maintaner-mode to unconditionally enable
the sections so that the maintainers are made aware that there is
a problem.


r~

Re: Building of generated parser files

[Joel Sherrill]

On Sat, 23 Aug 1997, Ian Lance Taylor wrote:

> Version problems.  These are particularly obvious for the cases of
> autoconf and automake.  However, I've also run into version problems
> with makeinfo, in which I had an old makeinfo which didn't understand
> some new commands.  The point is not that these problems can't be
> fixed, but that people who don't understand or don't care about them
> should not have to worry about them.

I have run into the makinfo problem myself.  Old versions of makeinfo are
missing a LOT of features found in the newer ones.

--joel

Re: Building of generated parser files

[Jim Meyering]

Ian Lance Taylor <ian@cygnus.com> writes:

|    Date: Sat, 23 Aug 1997 19:02:57 -0400
|    From: Richard Stallman <rms@gnu.ai.mit.edu>
|
|    What do people propose for --enable-maintainer-mode to mean?
|
| --enable-maintainer-mode is currently being used by automake.
|
| If --enable-maintainer-mode is used when you configure, it means that
| you will get a Makefile which will automatically rebuild Makefile.in
| from Makefile.am using automake, and automatically rebuild configure
| from configure.in using autoconf, among other automatic dependencies.
|
| If you do not use --enable-maintainer-mode, then you will have to
| explicitly rebuild Makefile.in, configure.in, and other files by hand.

FYI, the fileutils, sh-utils, and textutils have been providing
--enable-maintainer-mode for over a year.  It seems to have had
the desired effect.

Re: Building of generated parser files

[Richard Stallman]

There are rules for what certain kinds of configure options
ought to mean; departing from the rules is not good for the
coherence of the whole GNU system.

Since --with options have one specific kind of meaning
(describing what else is installed on the system)
and --enable options have another specific kind of meaning
(specifying optional parts of the package to build),
and these two meanings have no overlap,
the idea that a --enable option could be a good abbreviation for
a collection of --with options is rather implausible.

What do people propose for --enable-maintainer-mode to mean?

Re: Building of generated parser files

[Ian Lance Taylor]

   From: Richard Henderson <rth@cygnus.com>
   Date: Sat, 23 Aug 1997 11:07:46 -0700 (PDT)

   > Ok I dived into doing the stuff I proposed some hours ago.  To me it
   > seems like a way to go generally in GNU sw.  I enclose a patch below
   > that shows the ideas.  I only handle the --with-makeinfo switch as
   > this is more of a proof of concept than anything else.  Similar
   > patches can be made for --with-bison, --with-texi2dvi, etc.

   Why not just detect which programs are available and enable
   all found?  I presume it is not the fractional extra build time
   that is the reason for wanting to conditionalize this.

Version problems.  These are particularly obvious for the cases of
autoconf and automake.  However, I've also run into version problems
with makeinfo, in which I had an old makeinfo which didn't understand
some new commands.  The point is not that these problems can't be
fixed, but that people who don't understand or don't care about them
should not have to worry about them.

Ian

Re: Building of generated parser files

[David Bristow]

 Why not use makeinfo --version, bison --version, automake --version, etc.,
to find out what version they have installed, and whether or not that
version is sufficient for egcs to use?

David Bristow
dbristow@cybercom.net

-----Original Message-----
From: Joel Sherrill <joel@OARcorp.com>
To: Ian Lance Taylor <ian@cygnus.com>
Cc: egcs@cygnus.com <egcs@cygnus.com>
Date: Saturday, August 23, 1997 4:42 PM
Subject: Re: Building of generated parser files



>
>
>On Sat, 23 Aug 1997, Ian Lance Taylor wrote:
>
>> Version problems.  These are particularly obvious for the cases of
>> autoconf and automake.  However, I've also run into version problems
>> with makeinfo, in which I had an old makeinfo which didn't understand
>> some new commands.  The point is not that these problems can't be
>> fixed, but that people who don't understand or don't care about them
>> should not have to worry about them.
>
>I have run into the makinfo problem myself.  Old versions of makeinfo are
>missing a LOT of features found in the newer ones.
>
>--joel

Re: Building of generated parser files

[Tom Tromey]

Richard> Why not just detect which programs are available and enable
Richard> all found?  I presume it is not the fractional extra build
Richard> time that is the reason for wanting to conditionalize this.

Richard> And possibly use --enable-maintaner-mode to unconditionally
Richard> enable the sections so that the maintainers are made aware
Richard> that there is a problem.

Automake actually has two different facilities for handling this
problem.

The first, --enable-maintainer-mode, we all know about.

The other is a program called `missing'.  At configure time an
automake-using package looks for the standard (but frequently missing)
tools your package might use: autoconf, automake, etc.  If it exists,
fine.  If not, the program name as written into the Makefile is (eg)
"missing automake".

Then if your make tries to run automake, you get a helpful message
telling you what has gone wrong, and then the appropriate output files
are touched.  The idea here is that if you don't have automake then
you probably are just the victim of a losing system (eg, clock skew on
the network).

Here's the automake branch of `missing':

  automake)
    echo 1>&2 "\
WARNING: \`$1' is missing on your system.  You should only need it if
         you modified \`Makefile.am', \`acinclude.m4' or \`configure.in'.
         You might want to install the \`Automake' and \`Perl' packages.
         Grab them from any GNU archive site."
    find . -type f -name Makefile.am -print \
      | sed 's/^\(.*\).am$/touch \1.in/' \
      | sh
    ;;


I don't much like the idea of --with-bison, --with-autoconf, etc.  I
run a pretty full system.  Typing a dozen --with- options just to make
the development environment work seems painful.

Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

Re: Building of generated parser files

[Jim Wilson]

	 Why not use makeinfo --version, bison --version, automake --version, etc.,
	to find out what version they have installed, and whether or not that
	version is sufficient for egcs to use?

Because maintaining the database of working/not-working version numbers is
extra work for us, and likely to be errorprone.  This also introduces other
problems of its own.  What do we do about future version numbers?  If a future
release of makeinfo happens to have a bug or new feature that causes it to
fail for egcs, how does the current egcs sources know that it isn't supposed
to use it?  We certainly don't want to disallow all future versions, since
that would be too inconvenient.

Since we have to rely on human intelligence in the end anyways, we may as well
take advantage of this and keep the patch simple.  A simple binary option
--enable-maintainer-mode/--disable-maintainer-mode is all we need.  Anyone
who uses --enable-maintainer-mode will have to be able to deal with any
potential version number problems.  More complicated solutions are certainly
possible, but there aren't enough advantages to them to justify making gcc
more complicated than it already is.

Jim

Re: Building of generated parser files

[Richard Stallman]

    The intention is that people who configure normally, without
    --enable-maintainer-mode, will not have to worry about the timestamp
    of their configure.in vs. their configure, and so forth.  This matters
    because most people will not have autoconf or automake installed.

    I believe this is a correct use of a --enable option for configure.

It sounds correct to me.

    We are discussing making the gcc configure script support
    --enable-maintainer-mode to not rebuild the info files from the
    texinfo files.

That seems like a legitimate use of an --enable option,
but I am not sure the change is actually an improvement.

Re: Building of generated parser files

[Ian Lance Taylor]

   Date: Sat, 23 Aug 1997 14:44:54 +0200
   From: Niklas Hallqvist <niklas@petra.appli.se>

   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?

One appropriate place for further discussion might be
configure@cygnus.com, which is a general GNU list for configuration
issues.

Personally, I like --enable-maintainer-mode, and I think we should go
with it.

   >    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?

Yes.  I was only considering the within directory case.  In any case,
it's not a universal solution; it only helps within the context of a
single organization.

Ian

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

Re: Building of generated parser files

[Ian Lance Taylor]

   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.

   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.

Ian

Re: Building of generated parser files

[Andreas Schwab]

Niklas Hallqvist <niklas@petra.appli.se> writes:

|> Ok I dived into doing the stuff I proposed some hours ago.  To me it
|> seems like a way to go generally in GNU sw.  I enclose a patch below
|> that shows the ideas.  I only handle the --with-makeinfo switch as
|> this is more of a proof of concept than anything else.  Similar
|> patches can be made for --with-bison, --with-texi2dvi, etc.

|> Comments?

|> Niklas

|> Index: configure.in
|> ===================================================================
|> RCS file: /l/cvs/egcs/configure.in,v
|> retrieving revision 1.1.1.1
|> diff -u -r1.1.1.1 configure.in
|> --- configure.in	1997/08/22 08:53:13	1.1.1.1
|> +++ configure.in	1997/08/22 09:52:09
|> @@ -44,6 +44,12 @@
|>  gas=yes,
|>  gas=no)
 
|> +# With GNU makeinfo
|> +AC_ARG_WITH(makeinfo,
|> +[  --with-makeinfo         arrange to work with GNU makeinfo.],
|> +makeinfo=yes,

This should be `makeinfo=$withval', perhaps verifying first that $withval
is one of yes|no.  Otherwise you get surprising results when you say
--without-makeinfo or --with-makeinfo=no

Andreas.

Re: Building of generated parser files

[Niklas Hallqvist]

Ok I dived into doing the stuff I proposed some hours ago.  To me it
seems like a way to go generally in GNU sw.  I enclose a patch below
that shows the ideas.  I only handle the --with-makeinfo switch as
this is more of a proof of concept than anything else.  Similar
patches can be made for --with-bison, --with-texi2dvi, etc.

Comments?

Niklas

Index: configure.in
===================================================================
RCS file: /l/cvs/egcs/configure.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure.in
--- configure.in	1997/08/22 08:53:13	1.1.1.1
+++ configure.in	1997/08/22 09:52:09
@@ -44,6 +44,12 @@
 gas=yes,
 gas=no)
 
+# With GNU makeinfo
+AC_ARG_WITH(makeinfo,
+[  --with-makeinfo         arrange to work with GNU makeinfo.],
+makeinfo=yes,
+makeinfo=no)
+
 # With stabs
 AC_ARG_WITH(stabs,
 [  --with-stabs            arrange to use stabs instead of host debug format.],
@@ -3034,6 +3040,16 @@
     done
 fi
 
+# Customize depending on if we want info files generated or not.
+if [[ x$makeinfo = xyes ]]
+then
+    info_target=info
+    geninfodir=$srcdir
+else
+    info_targer=
+    geninfodir=.
+fi
+
 # Process the language and host/target makefile fragments.
 ${CONFIG_SHELL-/bin/sh} $srcdir/configure.frag $srcdir "$subdirs" "$dep_host_xmake_file" "$dep_tmake_file"
 
@@ -3077,6 +3093,8 @@
 AC_SUBST(maybe_use_collect2)
 AC_SUBST(cc_set_by_configure)
 AC_SUBST(stage_prefix_set_by_configure)
+AC_SUBST(geninfodir)
+AC_SUBST(info_target)
 
 AC_SUBST_FILE(target_overrides)
 AC_SUBST_FILE(host_overrides)
Index: Makefile.in
===================================================================
RCS file: /l/cvs/egcs/Makefile.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile.in
--- Makefile.in	1997/08/22 08:53:04	1.1.1.1
+++ Makefile.in	1997/08/22 10:17:26
@@ -235,6 +235,14 @@
 # Dir for temp files.
 tmpdir = /tmp
 
+# Section controlling generated files that are being shipped in releases.
+# The tools for generating these are not always available, so the building
+# of them should be optional even if they appear out-of-date.
+# Directories where generated files are to be found
+geninfodir = @geninfodir@
+# Targets controlling whether the files should be generated at all.
+info_target = @info_target@
+
 # Additional system libraries to link with.
 CLIB=
 
@@ -1971,15 +1979,17 @@
 #\f
 # Remake the info files.
 
-doc: info
-info: $(srcdir)/cpp.info $(srcdir)/gcc.info lang.info
+doc: $(info_target)
+info: $(geninfodir)/cpp.info $(geninfodir)/gcc.info lang.info
 
-$(srcdir)/cpp.info: cpp.texi
-	cd $(srcdir); $(MAKEINFO) $(MAKEINFOFLAGS) cpp.texi
+$(geninfodir)/cpp.info: cpp.texi
+	cd $(geninfodir); $(MAKEINFO) $(MAKEINFOFLAGS) -P $(srcdir) \
+		$(srcdir)/cpp.texi
 
-$(srcdir)/gcc.info: gcc.texi extend.texi install.texi invoke.texi \
+$(geninfodir)/gcc.info: gcc.texi extend.texi install.texi invoke.texi \
 		md.texi rtl.texi tm.texi gcov.texi
-	cd $(srcdir); $(MAKEINFO) $(MAKEINFOFLAGS) gcc.texi
+	cd $(geninfodir); $(MAKEINFO) $(MAKEINFOFLAGS) -P $(srcdir) \
+		$(srcdir)/gcc.texi
 
 dvi: $(srcdir)/gcc.dvi $(srcdir)/cpp.dvi lang.dvi
 
@@ -1993,8 +2003,8 @@
 	$(TEXI2DVI) $<
 
 $(srcdir)/INSTALL: install1.texi install.texi
-	$(MAKEINFO) -D INSTALLONLY --no-header --no-split \
-	  `echo $(srcdir)/install1.texi | sed 's,^\./,,'`
+	$(MAKEINFO) $(MAKEINFOFLAGS) -D INSTALLONLY --no-header \
+		--no-split `echo $(srcdir)/install1.texi | sed 's,^\./,,'`
 #\f
 # Deletion of files made during compilation.
 # There are four levels of this:
@@ -2244,7 +2254,7 @@
 # Install the info files.
 install-info: doc installdirs lang.install-info
 	-rm -f $(infodir)/cpp.info* $(infodir)/gcc.info*
-	cd $(srcdir); for f in cpp.info* gcc.info*; \
+	cd $(geninfodir); for f in cpp.info* gcc.info*; \
 	do $(INSTALL_DATA) $$f $(infodir)/$$f; done
 	-chmod a-x $(infodir)/cpp.info* $(infodir)/gcc.info*
 
Index: f/Make-lang.in
===================================================================
RCS file: /l/cvs/egcs/f/Make-lang.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Make-lang.in
--- Make-lang.in	1997/08/22 08:54:50	1.1.1.1
+++ Make-lang.in	1997/08/22 10:22:35
@@ -317,14 +317,17 @@
 f77.start.encap: g77 maybe-f2c
 f77.rest.encap: f77-runtime
 
-f77.info: $(srcdir)/f/g77.info
+f77.info: $(geninfodir)/f/g77.info
 f77.dvi: $(srcdir)/f/g77.dvi
 
 # g77 documentation.
-$(srcdir)/f/g77.info: f/g77.texi f/bugs.texi f/install.texi f/news.texi f/intdoc.texi
-	cd $(srcdir)/f; $(MAKEINFO) g77.texi
+$(geninfodir)/f/g77.info: f/g77.texi f/bugs.texi f/install.texi f/news.texi \
+  f/intdoc.texi
+	$(MAKEINFO) $(MAKEINFOFLAGS) -P $(srcdir)/f \
+		-o $(geninfodir)/f/g77.info $(srcdir)/f/g77.texi
 
-$(srcdir)/f/g77.dvi: f/g77.texi f/bugs.texi f/install.texi f/news.texi f/intdoc.texi
+$(srcdir)/f/g77.dvi: f/g77.texi f/bugs.texi f/install.texi f/news.texi \
+  f/intdoc.texi
 	cd $(srcdir)/f; $(TEXI2DVI) g77.texi
 
 $(srcdir)/f/intdoc.texi: f/intdoc.c f/intdoc.h f/intrin.def f/intrin.h
@@ -333,17 +336,20 @@
 	f/intdoc > $(srcdir)/f/intdoc.texi
 	rm f/intdoc
 
-$(srcdir)/f/BUGS: f/bugs0.texi f/bugs.texi
-	cd $(srcdir)/f; $(MAKEINFO) -D BUGSONLY --no-header --no-split \
-	  --no-validate bugs0.texi -o BUGS
-
-$(srcdir)/f/INSTALL: f/install0.texi f/install.texi
-	cd $(srcdir)/f; $(MAKEINFO) -D INSTALLONLY --no-header --no-split \
-	  --no-validate install0.texi -o INSTALL
-
-$(srcdir)/f/NEWS: f/news0.texi f/news.texi
-	cd $(srcdir)/f; $(MAKEINFO) -D NEWSONLY --no-header --no-split \
-	  --no-validate news0.texi -o NEWS
+$(geninfodir)/f/BUGS: f/bugs0.texi f/bugs.texi
+	cd $(geninfodir)/f; $(MAKEINFO) $(MAKEINFOFLAGS) -P $(srcdir)/f \
+		-D BUGSONLY --no-header --no-split --no-validate \
+		$(srcdir)/f/bugs0.texi -o BUGS
+
+$(geninfodir)/f/INSTALL: f/install0.texi f/install.texi
+	cd $(geninfodir)/f; $(MAKEINFO) $(MAKEINFOFLAGS)  -P $(srcdir)/f \
+		-D INSTALLONLY --no-header --no-split --no-validate \
+		$(srcdir)/f/install0.texi -o INSTALL
+
+$(geninfodir)/f/NEWS: f/news0.texi f/news.texi
+	cd $(geninfodir)/f; $(MAKEINFO) $(MAKEINFOFLAGS)  -P $(srcdir)/f \
+		-D NEWSONLY --no-header --no-split --no-validate \
+		$(srcdir)/f/news0.texi -o NEWS
 
 $(srcdir)/f/runtime/configure: $(srcdir)/f/runtime/configure.in 
 	cd f/runtime && $(MAKE) srcdir=../../$(srcdir)/f/runtime -f ../../$(srcdir)/f/runtime/Makefile.in rebuilt
@@ -437,7 +443,7 @@
 
 f77.install-info:
 	-rm -f $(infodir)/g77.info*
-	cd $(srcdir)/f; for f in g77.info*; \
+	cd $(geninfodir)/f; for f in g77.info*; \
 	do $(INSTALL_DATA) $$f $(infodir)/$$f; done
 	-chmod a-x $(infodir)/g77.info*
 

Re: Building of generated parser files

[Niklas Hallqvist]

> Date: Thu, 21 Aug 1997 15:23:08 -0400
> From: Michael Meissner <meissner@cygnus.com>
> 
> One of the differences between Cygnus builds and FSF builds is where
> things like the generated parser files get built.  Under the Cygnus
> tree, they get built in the object directory and under the FSF (and
> now egcs) scheme, they get built in the source directory.  This causes
> problems when using a CVS tree (ie, when you next do a cvs update, it
> considers the file to be different and merges in the changes).  It can
> also play havoc if you want to mount the sources on a read-only
> media.  One of the downsides of the Cygnus approach is that you need a
> parser generator available (this isn't a problem in Cygnus builds,
> because we include a special version of byacc in our tree that gets
> built before the compiler builds).  Given we've talked about allowing
> remote CVS access to the tree, I suspect more people will run into
> this.

This has been my pet peeve for years.  Early on because it could break
parallel builds, and lately because of CVS.  Up to now I have used to
patch the sources to build generated files in the objdir always, just
like Cygnus' seems to be doing.  The problem is getting worse for me
personally as the project I am involved in redistributes GNU source
via an anonymous CVS service and users gets these kinds of problems in
each and every GNU package more often.  We don't want to touch the
source at all but rather keep a wrapper Makefile that encapsulates the
special attributes of our environment, however for these problems we
have to be more intrusive.

So I have begun thinking a little towards coming up with something
general that could be proposed for all GNU software, and which does
not need all the tools.

What about using --with-makeinfo and friends to configure?  If a
"generator tool" exists the makefile will contain code that builds
into the objdir, and the generating makerules will be present and
depending on the source.  If not, the generated files will be sought
for in the srcdir like now, but the generating rule will either not be
present ornot depend on the source file, i.e. you have to explictly
type "make gcc.info" to build it, even if the .texi files is newer.
In the latter case the user will of course have to see to that the
tool needed is installed.

Comments?  Do you think it adds too much flexibility and thus makes
debugging bug-reports more problematic?  Is it a bad idea for other
reasons?  I volunteer to explore the area deeper if it seems like a
good idea.

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.

Niklas

Re: Building of generated parser files

[Jim Wilson]

	(this isn't a problem in Cygnus builds,
	because we include a special version of byacc in our tree that gets
	built before the compiler builds)

The special version of byacc that Cygnus uses is a historical oddity.
There is no reason to consider byacc for egcs.  If we want to include
a parser generator, it should be bison.

Jim

Re: Building of generated parser files

[Per Bothner]

> I don't think we should have a dependency on a pre-existing C++ compiler.
> Are you going to include a C source for gperf (maybe generated by cfront) ?

We should probably use cperf instead of gperf.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: Building of generated parser files

[meissner]

| I don't think we should have a dependency on a pre-existing C++ compiler.
| Are you going to include a C source for gperf (maybe generated by cfront) ?

Well there is cperf that's been floating around the net for years, that is
written in C.

I suspect that this is like the case of bfd, where you need to do special steps
to build bfd-in2.h (ie, make headers).  The recent --enable-maintainer-mode
could be used for the compiler as well.

This is the same issue as autoconf/autoheader (which BTW, just bit me in
building an AIX version of egcs).

Re: Building of generated parser files

[Joern Rennecke]

> | > I
> | > would also go as to remove the generated parser files and info, and
> | > generate them in the object directory as part of the build process.
> | 
> | What about the two files that can be regenerated by gperf?
> 
> Of course this is a slippery slope, but I would include gperf and build them at
> runtime.

I don't think we should have a dependency on a pre-existing C++ compiler.
Are you going to include a C source for gperf (maybe generated by cfront) ?

Re: Building of generated parser files

[Fred Fish]

> I
> would also go as to remove the generated parser files and info, and
> generate them in the object directory as part of the build process.

What about the two files that can be regenerated by gperf?

-Fred

Building of generated parser files

[Michael Meissner]

One of the differences between Cygnus builds and FSF builds is where
things like the generated parser files get built.  Under the Cygnus
tree, they get built in the object directory and under the FSF (and
now egcs) scheme, they get built in the source directory.  This causes
problems when using a CVS tree (ie, when you next do a cvs update, it
considers the file to be different and merges in the changes).  It can
also play havoc if you want to mount the sources on a read-only
media.  One of the downsides of the Cygnus approach is that you need a
parser generator available (this isn't a problem in Cygnus builds,
because we include a special version of byacc in our tree that gets
built before the compiler builds).  Given we've talked about allowing
remote CVS access to the tree, I suspect more people will run into
this.

Assuming we move the compiler down one level, and have a toplevel ala
current binutils/gdb (ie, the Cygnus toplevel), we probably should
think about including bison/byacc and makeinfo (gperf?) in the trees,
so that the generated files can be generated easily at runtime.  It
will increase the size of the tree.  Maybe move the tools into a
separate tarball, so that they aren't downloaded all of the time.  I
would also go as to remove the generated parser files and info, and
generate them in the object directory as part of the build process.

-- 
Michael Meissner, Cygnus Solutions (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

Re: Building of generated parser files

[meissner]

| > I
| > would also go as to remove the generated parser files and info, and
| > generate them in the object directory as part of the build process.
| 
| What about the two files that can be regenerated by gperf?

Of course this is a slippery slope, but I would include gperf and build them at
runtime.