Documenting tools necessary for GCC [draft]

Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

At the GCC BOF where topics relating to process and maintenence were
discussed, one of the issues was tools (and acceptable versions) that
are necessary for building and/or modifying GCC.

I volunteered to document it, here's my first draft.  I marked '???'
in places where I was unsure of specifics.  I'd like general comments
and feedback on missing or incorrect content.

I'm bad at designing and implementing formatting, so I left it in text
form for now.  If someone wants to convert into an HTML page suitable
for our website, that would also be appreciated.

		Thanks,
		--Kaveh





Tools necessary for building and/or developing GCC



To build GCC:

------------------------------------------------------
ISO C90 compiler

Necessary to bootstrap the GCC package, although versions of GCC prior
to 3.4 also allow bootstrapping with a traditional (K&R) C compiler.

To make all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed, you need to start with an existing
GCC binary because source code for language frontends other than C
might use GCC extensions.

------------------------------------------------------
A working Bourne (or compatible) shell, or
GNU bash version 2.??? (or later)

Necessary when running configure because some /bin/sh shells have bugs
or disastrous corner-case performance problems.  Set CONFIG_SHELL in
your environment to your "good" shell prior to running configure/make.
Sometimes /bin/ksh is sufficient, sometimes it isn't.  See the
host/target specific instructions for your platform, or use bash to be
sure.

------------------------------------------------------
GNU make version 3.79.1 (later versions okay for building only.)

Necessary when running "make" to build the GCC package.

------------------------------------------------------
GNU binutils version ???

Necessary in some circumstances, optional in others.  See the
host/target specific instructions for your platform for the exact
requirements.

------------------------------------------------------
gzip version 1.2.4 (or later) or
bzip2 version ??? (or later)

Necessary to uncompress gcc tar files when source code is obtained via
FTP mirror sites.

------------------------------------------------------




To develop/modify GCC (all of the above tools plus):

------------------------------------------------------
autoconf version 2.13 (NO earlier or later versions)
GNU m4 version 1.4 (or later)

Necessary when modifying configure.in, aclocal.m4, etc to regenerate
configure and config.in files

------------------------------------------------------
automake version ???

Necessary when modifying a Makefile.am to regenerate its associated
Makefile.in

------------------------------------------------------
gperf version 2.7.2 (or later)

Necessary when modifying gperf input files, e.g. gcc/cp/cfns.gperf to
regenerate its associated header file, e.g. gcc/cp/cfns.h.

------------------------------------------------------
expect version ???
tcl version ???
dejagnu version ???

Necessary to run the GCC testsuite.

------------------------------------------------------
autogen version ???
guile version ???

Necessary when modifying fixinc/inclhack.def or fixinc/*.tpl to
regenerate fixinc/fixincl.x.

------------------------------------------------------
GNU make version 3.79.1 (NO other versions)

This entry is duplicated from the "build" section and marked "no other
versions" to indicate that Makefile extensions from this specific
release of GNU make are allowed to be used and relied upon.
Extensions introduced in later versions of GNU make are not allowed.

------------------------------------------------------
GNU Bison version 1.28 (or later)
Flex version 2.5.4 (or later)

Necessary when modifying *.y (bison) or *.l (flex).

Necessary to build GCC during development because the generated output
files are not included in the cvs repository.  They are included in
releases.

------------------------------------------------------
makeinfo version 4.2 (or later)

Necessary when modifying *.texi files to test your changes.

Necessary to build GCC documentation during development because the
generated output files are not included in the cvs repository.  They
are included in releases.

------------------------------------------------------
cvs version ???
ssh version ???

Necessary to access the cvs repository.  Public releases and weekly
snapshots of the development sources are also available via FTP.

------------------------------------------------------
perl version 5.??? (or later)

Necessary when regenerating Makefile dependencies in libiberty.
Necessary when regenerating something with intl??? (pod2man???)
Other stuff???

------------------------------------------------------
GNU diffutils version 2.7 (or later)

Necessary when creating changes to GCC source code to submit for review.

------------------------------------------------------
patch version 2.5 (or later)

Necessary when applying patches, created with "diff", to one's own
sources.

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Thu, 29 May 2003, Kaveh R. Ghazi wrote:

> I'm bad at designing and implementing formatting, so I left it in text
> form for now.  If someone wants to convert into an HTML page suitable
> for our website, that would also be appreciated.

The appropriate location is install.texi, as this documentation ought to 
be branched for releases to describe what is needed on the particular 
release branch.  (And seek out all the places where version numbers are 
presently documented in install.texi or elsewhere, to unify the 
documentation of prerequisites.)

> To make all languages in a cross-compiler or other configuration where
> 3-stage bootstrap is not performed, you need to start with an existing
> GCC binary because source code for language frontends other than C
> might use GCC extensions.

For building cross-compilers it must (as documented in install.texi) be
GCC 2.95 or later.  There is also the documentation of Ada prerequisites
in install.texi.

> A working Bourne (or compatible) shell, or
> GNU bash version 2.??? (or later)

Is there any actual reason to suppose bash 1.x defective?

> Necessary when running configure because some /bin/sh shells have bugs
> or disastrous corner-case performance problems.  Set CONFIG_SHELL in
> your environment to your "good" shell prior to running configure/make.
> Sometimes /bin/ksh is sufficient, sometimes it isn't.  See the
> host/target specific instructions for your platform, or use bash to be
> sure.

When is ksh defective?

If we're recommending this, perhaps we can consider allowing POSIX shell
features (e.g. shell functions, negation of pipelines) to be used.  (The
POSIX shell standard was based on ksh, and any ksh or bash version likely
to be in use should suffice for the features that are likely to be
useful.)

> GNU make version 3.79.1 (later versions okay for building only.)
> 
> Necessary when running "make" to build the GCC package.

We've decided to desupport non-GNU make generally (not just for GNAT and
libjava)?

> automake version ???

1.4p? (whichever is the latest 1.4 patch release) but I don't know if this
is the case for all directories.

> makeinfo version 4.2 (or later)
> 
> Necessary when modifying *.texi files to test your changes.

You need both makeinfo and texi2dvi from a Texinfo installation (version
4.2 or later) - and a working TeX installation (no version number
relevant; any version now in use should suffice).

> ------------------------------------------------------
> perl version 5.??? (or later)
> 
> Necessary when regenerating Makefile dependencies in libiberty.
> Necessary when regenerating something with intl??? (pod2man???)
> Other stuff???

I'm sure that perl 5.6.1 or later suffices; earlier versions may work as
well if you upgrade the included Pod::Man.

> patch version 2.5 (or later)
> 
> Necessary when applying patches, created with "diff", to one's own
> sources.

Some versions of patch have had problems with patches to binary files,
which are now included in the diffs between GCC releases (message
catalogs).  Could you test whether patch 2.5 does indeed work with these
patches (i.e., generates the same tree as the tarballs); if not, 2.5.4 may
need to be recommended instead.

Not included in the above list:

libtool (a tricky case because what's used is based on a dead CVS branch).

gettext (only for regenerating gcc.pot) (the most recent release isn't yet
needed, though quite possibly it has useful features for GCC; I don't know
what exactly the correct required version is; Zack can probably advise).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Thu, May 29, 2003 at 06:54:00PM +0100, Joseph S. Myers wrote:
> > GNU make version 3.79.1 (later versions okay for building only.)
> > 
> > Necessary when running "make" to build the GCC package.
> 
> We've decided to desupport non-GNU make generally (not just for GNAT and
> libjava)?

We've tried to fix problems with the BSD makes, but new ones seem to keep
popping up.  I think that working with the BSD makes should be a goal,
but we have to document reality.
 

Re: Documenting tools necessary for GCC [draft]

[Eric Christopher]

On Thu, 2003-05-29 at 11:29, Joe Buck wrote:
> On Thu, May 29, 2003 at 06:54:00PM +0100, Joseph S. Myers wrote:
> > > GNU make version 3.79.1 (later versions okay for building only.)
> > > 
> > > Necessary when running "make" to build the GCC package.
> > 
> > We've decided to desupport non-GNU make generally (not just for GNAT and
> > libjava)?
> 
> We've tried to fix problems with the BSD makes, but new ones seem to keep
> popping up.  I think that working with the BSD makes should be a goal,
> but we have to document reality.
>  

Yes, and with the existing policy we have to support not just BSD and
GNU make, but Solaris make, Irix make, ...

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Thu, May 29, 2003 at 11:28:42AM -0700, Eric Christopher wrote:
> > We've tried to fix problems with the BSD makes, but new ones seem to keep
> > popping up.  I think that working with the BSD makes should be a goal,
> > but we have to document reality.
> >  
> 
> Yes, and with the existing policy we have to support not just BSD and
> GNU make, but Solaris make, Irix make, ...

We only said that we would support Posix-compliant makes.  I'm not sure
about Irix.  I know that some of the issues on some platforms were because
of broken vendor makes.
 

Re: Documenting tools necessary for GCC [draft]

[Eric Christopher]

On Thu, 2003-05-29 at 11:55, Joe Buck wrote:
> On Thu, May 29, 2003 at 11:28:42AM -0700, Eric Christopher wrote:
> > > We've tried to fix problems with the BSD makes, but new ones seem to keep
> > > popping up.  I think that working with the BSD makes should be a goal,
> > > but we have to document reality.
> > >  
> > 
> > Yes, and with the existing policy we have to support not just BSD and
> > GNU make, but Solaris make, Irix make, ...
> 
> We only said that we would support Posix-compliant makes.  I'm not sure
> about Irix.  I know that some of the issues on some platforms were because
> of broken vendor makes.
>  

No disagreement here. If it helps, I _know_ that irix make doesn't work
:)

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Thu, 29 May 2003, Joe Buck wrote:

> We only said that we would support Posix-compliant makes.  I'm not sure
> about Irix.  I know that some of the issues on some platforms were because
> of broken vendor makes.

Since POSIX knows nothing of VPATH, that also seems to imply some level of
support for in-source builds.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[Neil Booth]

Joe Buck wrote:-

> On Thu, May 29, 2003 at 06:54:00PM +0100, Joseph S. Myers wrote:
> > > GNU make version 3.79.1 (later versions okay for building only.)
> > > 
> > > Necessary when running "make" to build the GCC package.
> > 
> > We've decided to desupport non-GNU make generally (not just for GNAT and
> > libjava)?
> 
> We've tried to fix problems with the BSD makes, but new ones seem to keep
> popping up.  I think that working with the BSD makes should be a goal,
> but we have to document reality.

Kaveh is documenting what was agreed at the summit - we specify GNU
make only, and from now on we feel free to use all its extensions so as
to simplify our Makefile maintenance.  Yeah!

Neil.

Re: Documenting tools necessary for GCC [draft]

[Alexandre Oliva]

On May 31, 2003, Neil Booth <neil@daikokuya.co.uk> wrote:

> Kaveh is documenting what was agreed at the summit - we specify GNU
> make only, and from now on we feel free to use all its extensions so as
> to simplify our Makefile maintenance.  Yeah!

FWIW, what was agreed at the summit was that we were going to propose
this change to the other maintainers of the configury, namely, DJ
Delorie and Nathanael Nerode (not officially a maintainer (yet?), but
a very interested party :-).

Also, nobody has pointed out any reason for us to actually require to
GNU make, other than being able to point users at a version of make
that is known to work.  There were discussions about using GNU
make-specific features, but nobody could give me a good example of
what exact feature they had in mind.

I heard claims that one of the reasons to switch to GNU make was that
people weren't sure what was ok to add to a makefile and what wasn't.
IMO, requiring GNU make for this reason is a red herring.  You can use
non-portable shell constructs in GNUmakefiles just the same, and using
GNU make won't help in this regard.  Besides, checking for
non-portable configury features is exactly one of the reasons why we
have configury maintainers that know about these rules.  My opinion is
that, if you're unsure whether a feature is portable, either avoid
using it or ask one of the maintainers.  IMO, letting GNU make
features sneak in will eventually get us to a terribly complex build
machinery, like that of glibc.  I can't say that I'm looking forward
to maintaining something like that :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Alexandre Oliva <aoliva@redhat.com>
 > 
 > IMO, letting GNU make features sneak in will eventually get us to a
 > terribly complex build machinery, like that of glibc.  I can't say
 > that I'm looking forward to maintaining something like that :-)

Really?  You think our current mix of 4 incompatible automakes, old
autoconf version and complex Makefile design would be made worse (more
complex) by standardizing on GNU make?  Can you support that
statement with specifics?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Alexandre Oliva]

On May 31, 2003, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

>> From: Alexandre Oliva <aoliva@redhat.com>
>> 
>> IMO, letting GNU make features sneak in will eventually get us to a
>> terribly complex build machinery, like that of glibc.  I can't say
>> that I'm looking forward to maintaining something like that :-)

> Really?  You think our current mix of 4 incompatible automakes, old
> autoconf version and complex Makefile design would be made worse (more
> complex) by standardizing on GNU make?

Nope.  I think using only portable make features is not a significant
obstacle.  The use of different versions of automake has absolutely
nothing to do with standardizing on any particular version of make.
All versions of automake we use generate portable make code.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Documenting tools necessary for GCC [draft]

[Alexandre Oliva]

On May 31, 2003, "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

> standardizing on GNU make?  Can you support that statement with
> specifics?

Note that I don't want to get in the way of adopting GNU make features
should they actually give us any improvement in Makefile
maintainability.  But forcing it upon our users just because we're not
comfortable asking others whether some make feature is portable or not
is not a good reason to switch.  So far, I haven't heard any good
reasons to switch, which is why I keep on looking for one (as opposed
to just rejecting the idea).

Anyway, until we have a patch that actually introduces requirements on
GNU make, and that is clearly worth such a requirement, there's no
point in enforcing the use of GNU make.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Documenting tools necessary for GCC [draft]

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

[...]

| Anyway, until we have a patch that actually introduces requirements on
| GNU make, and that is clearly worth such a requirement, there's no
| point in enforcing the use of GNU make.

seconded.

As Alexandre, I would like to understand why and the benefits of this
decision.  

(I wish I was able to attend the GCC summit).

-- Gaby

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Sat, 31 May 2003, Gabriel Dos Reis wrote:

> As Alexandre, I would like to understand why and the benefits of this
> decision.  
> 
> (I wish I was able to attend the GCC summit).

Will there be sound recordings (ogg or mp3) made available of the
discussions leading to specific policy decisions (e.g., to mandate GNU
make), together with transcripts of at least the actual decisions?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[Diego Novillo]

On Sat, 2003-05-31 at 17:37, Joseph S. Myers wrote:

> Will there be sound recordings (ogg or mp3) made available of the
> discussions leading to specific policy decisions (e.g., to mandate GNU
> make)
>
I don't think there was any recording device at the BOF.

> together with transcripts of at least the actual decisions?
>
Ben Kosnik was keeping minutes, I believe.


Diego.

Re: Documenting tools necessary for GCC [draft]

[Toon Moene]

Joseph S. Myers wrote:

> Will there be sound recordings (ogg or mp3) made available of the
> discussions leading to specific policy decisions (e.g., to mandate GNU
> make), together with transcripts of at least the actual decisions?

Duh !  I hope no-one gets from the messages about this subject that some 
sort of decision was made at the GCC Summit.

We were just discussing options.  One of them I offered was that GNU 
make is more portable than makefiles themselves.  I said that because I 
have first-hand experience using make and GNU make on such varied 
platforms like Cray (both T3{D|E} and "classic"), Fujitsu VPP700/5000, 
NEC SX{4|5|6} - platforms most GNU "volunteers" do not have access to.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: Documenting tools necessary for GCC [draft]

[Geert Bosch]

On Saturday, May 31, 2003, at 17:25 America/New_York, Alexandre Oliva 
wrote:
> Anyway, until we have a patch that actually introduces requirements on
> GNU make, and that is clearly worth such a requirement, there's no
> point in enforcing the use of GNU make.

One of the concrete issues that came up is the ability to use
include files. The feature is available in most makes, but with
different and incompatible syntax. Standardizing on a single make
(regardless of the actual choice) would allow usage of the feature.

Another issue that we found with the GNAT front end, is that with
the extra GNU make features one doesn't need to rely as much on shell
capabilities. In our experience, using GNU make features was more
portable than relying on shell features across platforms.

Personally, I have found it tremendously helpful to be able to go
to one manual to find all constructs documented. Having the language
used for Makefiles specified as the least common denominator of 
languages
accepted by an open-ended set of "compatible" make utilities is a real
problem.

Requiring a specific version of make gives us instant documentation of
what may be used in the GCC makefiles.

   -Geert

Re: Documenting tools necessary for GCC [draft]

[Alexandre Oliva]

On Jun  1, 2003, Geert Bosch <bosch@gnat.com> wrote:

> One of the concrete issues that came up is the ability to use
> include files.

automake already has a macro that tests whether ${MAKE-make] supports
include, and it even supports both `include' and `.include' syntaxes.
We can do it without requiring GNU make.

> Another issue that we found with the GNAT front end, is that with
> the extra GNU make features one doesn't need to rely as much on shell
> capabilities.

You mean GNU make functions?  I'd much rather not start depending on
them.  I can see sometimes there may be benefits to doing so, but it
pretty much makes us entirely dependent on GNU make.  I could live
with that if the benefits are clearly worth it, but I don't want us to
use GNU make features just because we can.

> Personally, I have found it tremendously helpful to be able to go to
> one manual to find all constructs documented. Having the language
> used for Makefiles specified as the least common denominator of
> languages accepted by an open-ended set of "compatible" make
> utilities is a real problem.

Here's a (partial?) manual of the portable make features:

# <comments>
<MACRO> = <value>
<target> : [<dependency> ...] [ ; [@][-]<shell commands>]
[	[@][-]<shell commands> ...]

.SUFFIXES: [.<extension> ...]
.<extension>[.<extension>]:
[	[@][-]<shell commands> ...]

macros are referenced as $(MACRO) or ${MACRO}.  They may be referenced
in values and shell commands; their use in dependencies and targets is
also possible, but may have slightly different meanings; see below.
Other macros referenced in <value> are expanded at the location the
macro is expanded.  If a macro is defined more than once, the last
definition prevails, except when the macro is referenced in target or
dependencies, in which case the latest definition of the macro before
that point may be used.

Special macros such as $@ and $< denote the target and the
dependencies, respectively, and the latter should only be used in
shell commands in suffix rules.  $$ expands to the $ character.

Macros set in a Makefile may or may not be passed down to sub-makes.

Shell commands are written in whatever scripting language make starts
to run commands.  It can generally be assumed that this is some
variant of the Bourne Shell, but setting the SHELL macro may change
this.  Shell commands may take up multiple lines, as long as each
non-final line ends with a backslash, and each continuation line is
intended with a TAB.  For every occurrence of <shell commands>, a
separate shell interpreter is started, i.e., shell or environment
variables set in one <shell commands> aren't available in a separate
occurrence of <shell commands>.

> Requiring a specific version of make gives us instant documentation of
> what may be used in the GCC makefiles.

This is not entirely true.  See the manual above, and notice the
passage that discusses the syntax for shell commands.  That's where
most people introduce non-portable constructs, and choosing one
particular version of make won't help us in this regard.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Documenting tools necessary for GCC [draft]

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

>> Another issue that we found with the GNAT front end, is that with
>> the extra GNU make features one doesn't need to rely as much on shell
>> capabilities.
>
> You mean GNU make functions?  I'd much rather not start depending on
> them.  I can see sometimes there may be benefits to doing so, but it
> pretty much makes us entirely dependent on GNU make.  I could live
> with that if the benefits are clearly worth it, but I don't want us to
> use GNU make features just because we can.

This is pure speculation, but I'm pretty sure most of mklibgcc would
become unnecessary if we could use GNU make's pattern rules.

zw

Re: Documenting tools necessary for GCC [draft]

[Alexandre Oliva]

On Jun  2, 2003, Zack Weinberg <zack@codesourcery.com> wrote:

> This is pure speculation, but I'm pretty sure most of mklibgcc would
> become unnecessary if we could use GNU make's pattern rules.

It wouldn't be too hard to convince me of this, but ideally libgcc
should be moved into a separate top-level directory and handled by the
generic multilib machinery, which would obviate such pattern rules.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Documenting tools necessary for GCC [draft]

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jun  2, 2003, Zack Weinberg <zack@codesourcery.com> wrote:
>
>> This is pure speculation, but I'm pretty sure most of mklibgcc would
>> become unnecessary if we could use GNU make's pattern rules.
>
> It wouldn't be too hard to convince me of this, but ideally libgcc
> should be moved into a separate top-level directory and handled by the
> generic multilib machinery, which would obviate such pattern rules.

Yeah, I'd like to see that done, too.

zw

Re: Documenting tools necessary for GCC [draft]

[Kai Henningsen]

aoliva@redhat.com (Alexandre Oliva)  wrote on 31.05.03 in <orvfvrm1l2.fsf@livre.redhat.lsd.ic.unicamp.br>:

> I heard claims that one of the reasons to switch to GNU make was that
> people weren't sure what was ok to add to a makefile and what wasn't.

I'm not sure how much this will actually help, but POSIX 2001 make is  
described at
        http://www.opengroup.org/onlinepubs/007904975/utilities/make.html

MfG Kai

Re: Documenting tools necessary for GCC [draft]

[Phil Edwards]

> On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
> > Necessary when running configure because some /bin/sh shells have bugs
> > or disastrous corner-case performance problems.  Set CONFIG_SHELL in
> > your environment to your "good" shell prior to running configure/make.

Isn't setting SHELL also required?


On Thu, May 29, 2003 at 06:54:00PM +0100, Joseph S. Myers wrote:
> If we're recommending this, perhaps we can consider allowing POSIX shell
> features (e.g. shell functions, negation of pipelines) to be used.  (The
> POSIX shell standard was based on ksh, and any ksh or bash version likely
> to be in use should suffice for the features that are likely to be
> useful.)

We could say this, but there wouldn't be much point.  We use autoconf,
and autoconf doesn't make use of any "twentieth century shell" features
such as functions.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Phil Edwards <phil@jaj.com>
 > 
 > > On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
 > > > Necessary when running configure because some /bin/sh shells have bugs
 > > > or disastrous corner-case performance problems.  Set CONFIG_SHELL in
 > > > your environment to your "good" shell prior to running configure/make.
 > 
 > Isn't setting SHELL also required?

No, it shouldn't be required.  I've been setting just CONFIG_SHELL
without any problems.

IIRC, configure substitutes SHELL = @CONFIG_SHELL@ (or something
eventually equivalent) in each Makefile as they are generated, so
setting SHELL is redundant.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > The appropriate location is install.texi, as this documentation ought to 
 > be branched for releases to describe what is needed on the particular 
 > release branch.

Ok I'll move stuff to install.texi, though I'm far from a texi expert.
What section should it go in?


 > (And seek out all the places where version numbers are presently
 > documented in install.texi or elsewhere, to unify the documentation
 > of prerequisites.)

Yes worthwhile goal, but unlikely I'll find all places in the first go
around.  I think we'll have to find these over time and consolidate as
they are noticed.


 > > To make all languages in a cross-compiler or other configuration where
 > > 3-stage bootstrap is not performed, you need to start with an existing
 > > GCC binary because source code for language frontends other than C
 > > might use GCC extensions.
 > 
 > For building cross-compilers it must (as documented in install.texi) be
 > GCC 2.95 or later.  There is also the documentation of Ada prerequisites
 > in install.texi.

Thanks, I added 2.95 and an Ada section.



 > > A working Bourne (or compatible) shell, or
 > > GNU bash version 2.??? (or later)
 > 
 > Is there any actual reason to suppose bash 1.x defective?

<shrug>


 > > Necessary when running configure because some /bin/sh shells have bugs
 > > or disastrous corner-case performance problems.  Set CONFIG_SHELL in
 > > your environment to your "good" shell prior to running configure/make.
 > > Sometimes /bin/ksh is sufficient, sometimes it isn't.  See the
 > > host/target specific instructions for your platform, or use bash to be
 > > sure.
 > 
 > When is ksh defective?

David E mentioned that AIX ksh doesn't work, there may be others.  I
get intermitant failures on irix6.5 using ksh, but not on irix6.2.
OTOH, I use ksh on solaris2 and it always works, hence the hedging
about ksh.  I prefer not to document all the place where it works and
doesn't because this list will change in subtle ways every time we
modify the configure files.


 > > automake version ???
 > 
 > 1.4p? (whichever is the latest 1.4 patch release) but I don't know if this
 > is the case for all directories.

During the BOF, it was mentioned that we need four different and
incompatible versions of automake for the various directories.  (!!!)

I believe the plan is to upgrade all of them eventually to the latest
automake.  But I don't remember to what version (and it hasn't been
done yet, nor do I recall who if anyone volunteered to do it.)


 > > makeinfo version 4.2 (or later)
 > > 
 > > Necessary when modifying *.texi files to test your changes.
 > 
 > You need both makeinfo and texi2dvi from a Texinfo installation (version
 > 4.2 or later) - and a working TeX installation (no version number
 > relevant; any version now in use should suffice).

Hmm, I thought the dvi files were not part of the standard "make".
Don't you have to say "make dvi" ?  Also, I believe TeX is only
necessary if you "make dvi".  So I'll include them in their own
distinct section apart from making info files with makeinfo.



 > > ------------------------------------------------------
 > > perl version 5.??? (or later)
 > > 
 > > Necessary when regenerating Makefile dependencies in libiberty.
 > > Necessary when regenerating something with intl??? (pod2man???)
 > > Other stuff???
 > 
 > I'm sure that perl 5.6.1 or later suffices; earlier versions may work as
 > well if you upgrade the included Pod::Man.

Thanks, got it.


 > > patch version 2.5 (or later)
 > > 
 > > Necessary when applying patches, created with "diff", to one's own
 > > sources.
 > 
 > Some versions of patch have had problems with patches to binary files,
 > which are now included in the diffs between GCC releases (message
 > catalogs).  Could you test whether patch 2.5 does indeed work with these
 > patches (i.e., generates the same tree as the tarballs); if not, 2.5.4 may
 > need to be recommended instead.

I just wrote in 2.5.4.



 > Not included in the above list:
 > 
 > libtool (a tricky case because what's used is based on a dead CVS branch).

I don't understand this one.  Do we require someone hacking on GCC to
generate something with libtool when some file is modified?  If so,
which file(s) require (re)generation and touching which input files
make this necessary?


 > gettext (only for regenerating gcc.pot) (the most recent release isn't yet
 > needed, though quite possibly it has useful features for GCC; I don't know
 > what exactly the correct required version is; Zack can probably advise).

When does one need to regenerate gcc.pot?  I.e. when touching what
files?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[David Edelsohn]

>>>>> Kaveh R Ghazi writes:

>> When is ksh defective?

Kaveh> David E mentioned that AIX ksh doesn't work, there may be others.  I
Kaveh> get intermitant failures on irix6.5 using ksh, but not on irix6.2.
Kaveh> OTOH, I use ksh on solaris2 and it always works, hence the hedging
Kaveh> about ksh.  I prefer not to document all the place where it works and
Kaveh> doesn't because this list will change in subtle ways every time we
Kaveh> modify the configure files.

	Clarification: ksh *does* work on AIX, but it is unbearably slow.
Bash is preferred, but not necessary, for bootstrapping GCC on AIX.

David

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Thu, May 29, 2003 at 08:45:28PM -0400, David Edelsohn wrote:
> 	Clarification: ksh *does* work on AIX, but it is unbearably slow.
> Bash is preferred, but not necessary, for bootstrapping GCC on AIX.

That would explain it ... I tried building GCC on an old AIX box using
ksh, and it took literally days.
 

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Joe Buck <jbuck@synopsys.com>
 > 
 > On Thu, May 29, 2003 at 08:45:28PM -0400, David Edelsohn wrote:
 > > 	Clarification: ksh *does* work on AIX, but it is unbearably slow.
 > > Bash is preferred, but not necessary, for bootstrapping GCC on AIX.
 > 
 > That would explain it ... I tried building GCC on an old AIX box using
 > ksh, and it took literally days.

Yes, I considered the performance implosion another reason to get
bash.  I'll clarify that in the doc.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Phil Edwards]

On Thu, May 29, 2003 at 09:07:35PM -0400, Kaveh R. Ghazi wrote:
>  > From: Joe Buck <jbuck@synopsys.com>
>  > 
>  > On Thu, May 29, 2003 at 08:45:28PM -0400, David Edelsohn wrote:
>  > > 	Clarification: ksh *does* work on AIX, but it is unbearably slow.
>  > > Bash is preferred, but not necessary, for bootstrapping GCC on AIX.
>  > 
>  > That would explain it ... I tried building GCC on an old AIX box using
>  > ksh, and it took literally days.
> 
> Yes, I considered the performance implosion another reason to get
> bash.  I'll clarify that in the doc.

I've probably asked this before, but don't recall the answer:  why aren't
we detecting these conditions at the top of configure.in and re-exec'ing
the shell?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Phil Edwards <phil@jaj.com>
 > 
 > On Thu, May 29, 2003 at 09:07:35PM -0400, Kaveh R. Ghazi wrote:
 > >  > From: Joe Buck <jbuck@synopsys.com>
 > >  > 
 > >  > On Thu, May 29, 2003 at 08:45:28PM -0400, David Edelsohn wrote:
 > >  > > 	Clarification: ksh *does* work on AIX, but it is unbearably slow.
 > >  > > Bash is preferred, but not necessary, for bootstrapping GCC on AIX.
 > >  > 
 > >  > That would explain it ... I tried building GCC on an old AIX box using
 > >  > ksh, and it took literally days.
 > > 
 > > Yes, I considered the performance implosion another reason to get
 > > bash.  I'll clarify that in the doc.
 > 
 > I've probably asked this before, but don't recall the answer:  why aren't
 > we detecting these conditions at the top of configure.in and re-exec'ing
 > the shell?
 > Phil

Someone mentioned at the BOF that autoconf 2.5x does this
automagically.  I suppose we don't want to reinvent the wheel if we're
converting to a new verison (and IIRC we are.)

Someone (Ben?) was taking notes.  We need to post them so we can call
for volunteers for the various tasks we came up with.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Benjamin Kosnik]

>Someone (Ben?) was taking notes.  We need to post them so we can call
>for volunteers for the various tasks we came up with.

I sent the notes to Zack earlier today. 

-benjamin

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Thu, 29 May 2003, Kaveh R. Ghazi wrote:

> Ok I'll move stuff to install.texi, though I'm far from a texi expert.
> What section should it go in?

I'd suggest a new section on Prerequisites.  But creating new sections in
install.texi is difficult because of the funny way it generates multiple
HTML files and explicitly fills in all the @node fields for info (it could
do with being overhauled to use makeinfo's built-in support for split-file
HTML output, which wasn't available when the Texinfo version was
originally done, and to eliminate most or all of the explicit HTML in
there), so I find it is a matter of trial and error until all of "make
info", "make dvi" and install.texi2html work.

>  > > makeinfo version 4.2 (or later)
>  > > 
>  > > Necessary when modifying *.texi files to test your changes.
>  > 
>  > You need both makeinfo and texi2dvi from a Texinfo installation (version
>  > 4.2 or later) - and a working TeX installation (no version number
>  > relevant; any version now in use should suffice).
> 
> Hmm, I thought the dvi files were not part of the standard "make".
> Don't you have to say "make dvi" ?  Also, I believe TeX is only
> necessary if you "make dvi".  So I'll include them in their own
> distinct section apart from making info files with makeinfo.

You said "to test your changes" - and "make dvi" is part of the required
procedure for testing changes to the manual.

>  > gettext (only for regenerating gcc.pot) (the most recent release isn't yet
>  > needed, though quite possibly it has useful features for GCC; I don't know
>  > what exactly the correct required version is; Zack can probably advise).
> 
> When does one need to regenerate gcc.pot?  I.e. when touching what
> files?

It needs to be done (a) by the RM at various points; (b) when making
changes to the translation machinery that improve the number or quality of
messages that get into gcc.pot; (c) from time to time anyway (on
mainline).  In general changes that simply incidentally change messages
don't need to regenerate gcc.pot.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > > Hmm, I thought the dvi files were not part of the standard "make".
 > > Don't you have to say "make dvi" ?  Also, I believe TeX is only
 > > necessary if you "make dvi".  So I'll include them in their own
 > > distinct section apart from making info files with makeinfo.
 > 
 > You said "to test your changes" - and "make dvi" is part of the required
 > procedure for testing changes to the manual.

I'm curious about this requirement, when making changes to the manual
is there something that "make dvi" checks in terms of texi mistakes
that "make info" wouldn't catch?

We've already got a huge tools list.  I'd like to avoid forcing people
to get and install TeX if they don't have to.  And it seems to me that
if one doesn't want dvi files and if they're not part of the standard
"make install", then we should be able to say testing "make dvi" is
optional without losing any actual texi validation for changes to the
manual.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Sun, 1 Jun 2003, Kaveh R. Ghazi wrote:

> I'm curious about this requirement, when making changes to the manual
> is there something that "make dvi" checks in terms of texi mistakes
> that "make info" wouldn't catch?

Anything in conditional sections that aren't used for info.  (Problems
with conditional parts of manuals are more common with HTML output, so
perhaps "make html" which doesn't require extra tools should also be
included in the test procedures.)  That paragraph in contribute.html was
mainly intended for changes to the manual that are solely manual changes,
not those incidental to a code change, though the additional testing of
those is good as well.  Anything that only shows up ugly in printed output
(e.g., FOO_BAR_BAZ not inside @code or @samp - immediately obvious in the
printed output, not so in info).  Overfull hboxes (e.g. missing @gol in
option summary lists, the need for which arises from differences in how
makeinfo and texinfo.tex handle macros).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[Alexandre Oliva]

On May 29, 2003, "Joseph S. Myers" <jsm28@cam.ac.uk> wrote:

> Not included in the above list:

> libtool (a tricky case because what's used is based on a dead CVS branch).

Nobody needs anything from libtool that's not in the GCC tree.  The m4
macros used by autoconf are pulled from the top-level libtool.m4.  The
scripts used by libtool (ltconfig, ltmain.sh, ltcf-*.sh) are all used
from the top-level.  There's no need for anyone to have any libtool
version installed elsewhere, for build or development.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Documenting tools necessary for GCC [draft]

[Eric Christopher]

My thoughts:

> ------------------------------------------------------
> GNU binutils version ???
> 
> Necessary in some circumstances, optional in others.  See the
> host/target specific instructions for your platform for the exact
> requirements.
> 

This is good. I think we can either link or add information for target
specific features that require specific binutils versions
(explicit-relocs for alpha and mips come to mind, or tls, or...)

> ------------------------------------------------------
> gzip version 1.2.4 (or later) or
> bzip2 version ??? (or later)
> 
> Necessary to uncompress gcc tar files when source code is obtained via
> FTP mirror sites.
> 

gnu tar required? I seem to remember some deal with uncompressing gnu
tar archives with solaris tar not working.


> ------------------------------------------------------
> autogen version ???

Aaah. autogen comes with guile?

> guile version ???
> 
> Necessary when modifying fixinc/inclhack.def or fixinc/*.tpl to
> regenerate fixinc/fixincl.x.

> 
> ------------------------------------------------------
> cvs version ???
> ssh version ???
> 

probably 1.10 or greater for cvs. Ian would know best.


-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Eric Christopher <echristo@redhat.com>
 > 
 > My thoughts:
 > 
 > > ------------------------------------------------------
 > > gzip version 1.2.4 (or later) or
 > > bzip2 version ??? (or later)
 > > 
 > > Necessary to uncompress gcc tar files when source code is obtained via
 > > FTP mirror sites.
 > > 
 > 
 > gnu tar required? I seem to remember some deal with uncompressing gnu
 > tar archives with solaris tar not working.

Yeah, I've had gnu tar installed for so long I forgot.  Got it.



 > > ------------------------------------------------------
 > > autogen version ???
 > 
 > Aaah. autogen comes with guile?
 > 
 > > guile version ???

No, but it needs guile.  You get them separately.



 > > ------------------------------------------------------
 > > cvs version ???
 > > ssh version ???
 > > 
 > 
 > probably 1.10 or greater for cvs. Ian would know best.
 > -eric

I'm wondering if we should recommend openssh?  If so, what version?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
> I'm wondering if we should recommend openssh?  If so, what version?

As far as I recall, we must not recommend any version of SSH.COM's SSH
(that's clear) nor OpenSSH, but <http://www.lysator.liu.se/~nisse/lsh/>.

To that end, I'd really just specify SSH and nothing else, for I am not
aware of any interoperability in the last few years.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Documenting tools necessary for GCC [draft]

[Eric Christopher]

On Thu, 2003-05-29 at 23:46, Gerald Pfeifer wrote:
> On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
> > I'm wondering if we should recommend openssh?  If so, what version?
> 
> As far as I recall, we must not recommend any version of SSH.COM's SSH
> (that's clear) nor OpenSSH, but <http://www.lysator.liu.se/~nisse/lsh/>.
> 
> To that end, I'd really just specify SSH and nothing else, for I am not
> aware of any interoperability in the last few years.

Yes, I'd prefer to stay away from these sorts of political issues.
Specifying, say, GNU make because we want to pick a particular type of
make is one thing - getting into a which ssh battle just sounds like a
headache.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Fri, May 30, 2003 at 08:46:18AM +0200, Gerald Pfeifer wrote:
> On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
> > I'm wondering if we should recommend openssh?  If so, what version?
> 
> As far as I recall, we must not recommend any version of SSH.COM's SSH
> (that's clear) nor OpenSSH, but <http://www.lysator.liu.se/~nisse/lsh/>.

I don't understand: openssh is free software.

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Fri, 30 May 2003, Joe Buck wrote:
>> As far as I recall, we must not recommend any version of SSH.COM's SSH
>> (that's clear) nor OpenSSH, but <http://www.lysator.liu.se/~nisse/lsh/>.
> I don't understand: openssh is free software.

RMS had requested that last year or so; if it's important, I can try to
dig out details from my archives.

Gerald

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Fri, May 30, 2003 at 09:10:18PM +0200, Gerald Pfeifer wrote:
> On Fri, 30 May 2003, Joe Buck wrote:
> >> As far as I recall, we must not recommend any version of SSH.COM's SSH
> >> (that's clear) nor OpenSSH, but <http://www.lysator.liu.se/~nisse/lsh/>.
> > I don't understand: openssh is free software.
> 
> RMS had requested that last year or so; if it's important, I can try to
> dig out details from my archives.

"RMS requested" != "we must", at least not in all cases.

Perhaps we need to talk about that on the SC list.  This is the type of
request that we normally push back.

Re: Documenting tools necessary for GCC [draft]

[David O'Brien]

On Fri, May 30, 2003 at 09:10:18PM +0200, Gerald Pfeifer wrote:
> On Fri, 30 May 2003, Joe Buck wrote:
> >> As far as I recall, we must not recommend any version of SSH.COM's SSH
> >> (that's clear) nor OpenSSH, but <http://www.lysator.liu.se/~nisse/lsh/>.
> > I don't understand: openssh is free software.
> 
> RMS had requested that last year or so; if it's important, I can try to
> dig out details from my archives.

*sigh*  Does lsh even work very well?  All the Linux vendors I know of
ship with OpenSSH.

    From my SuSE Linux ES 8 machine:
    $ /usr/bin/ssh -v
    OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f

    From a Red Hat 8.0 (Psyche) box:
    $ ssh -v
    OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

-- 
-- David  (obrien@FreeBSD.org)

Re: Documenting tools necessary for GCC [draft]

[Eric Christopher]

> 
> *sigh*  Does lsh even work very well?  All the Linux vendors I know of
> ship with OpenSSH.

Agreed. Personally I'd rather just say that people need an ssh client
and leave it at that. I haven't heard of any incompatibilities for ssh
clients.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Eric Christopher <echristo@redhat.com>
 > 
 > > *sigh*  Does lsh even work very well?  All the Linux vendors I know of
 > > ship with OpenSSH.
 > 
 > Agreed. Personally I'd rather just say that people need an ssh client
 > and leave it at that. I haven't heard of any incompatibilities for ssh
 > clients.
 > -eric

Agreed, I'll just list that you need some ssh client.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Fri, May 30, 2003 at 12:43:14PM -0700, David O'Brien wrote:
> *sigh*  Does lsh even work very well?  All the Linux vendors I know of
> ship with OpenSSH.

I think that lsh was started when ssh went to a restrictive license, but
before openssh was released.  There's no longer a real reason for it.

Re: Documenting tools necessary for GCC [draft]

[DJ Delorie]

> ------------------------------------------------------
> perl version 5.??? (or later)
> 
> Necessary when regenerating Makefile dependencies in libiberty.

Any version should work fine.  I'm not into the fancy latest and
greatest gizmo thing.

Re: Documenting tools necessary for GCC [draft]

[E. Weddington]

On 29 May 2003 at 13:27, Kaveh R. Ghazi wrote:

> To develop/modify GCC (all of the above tools plus):
> ------------------------------------------------------
> GNU Bison version 1.28 (or later)
> Flex version 2.5.4 (or later)
> 
> Necessary when modifying *.y (bison) or *.l (flex).
> 
> Necessary to build GCC during development because the generated output
> files are not included in the cvs repository.  They are included in
> releases.
> ------------------------------------------------------

IIRC, bison and flex were both needed to *build* gcc for the avr target on 
mingw, not just to develop / modify. I don't know if this is a general case.

Eric Weddington

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: "E. Weddington" <eric@umginc.net>
 > 
 > On 29 May 2003 at 13:27, Kaveh R. Ghazi wrote:
 > 
 > > To develop/modify GCC (all of the above tools plus):
 > > ------------------------------------------------------
 > > GNU Bison version 1.28 (or later)
 > > Flex version 2.5.4 (or later)
 > > 
 > > Necessary when modifying *.y (bison) or *.l (flex).
 > > 
 > > Necessary to build GCC during development because the generated output
 > > files are not included in the cvs repository.  They are included in
 > > releases.
 > > ------------------------------------------------------
 > 
 > IIRC, bison and flex were both needed to *build* gcc for the avr target on 
 > mingw, not just to develop / modify. I don't know if this is a general case.
 > Eric Weddington

This shouldn't be required for released versions of GCC in any
configuration.  What version of GCC were you using?  Are you sure your
timestamps were correct?

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[E. Weddington]

On 29 May 2003 at 20:51, Kaveh R. Ghazi wrote:

>  > From: "E. Weddington" <eric@umginc.net>
>  > 
>  > On 29 May 2003 at 13:27, Kaveh R. Ghazi wrote:
>  > 
>  > > To develop/modify GCC (all of the above tools plus):
>  > > ------------------------------------------------------
>  > > GNU Bison version 1.28 (or later)
>  > > Flex version 2.5.4 (or later)
>  > > 
>  > > Necessary when modifying *.y (bison) or *.l (flex).
>  > > 
>  > > Necessary to build GCC during development because the generated output > >
>  files are not included in the cvs repository.  They are included in > >
>  releases. > > ------------------------------------------------------ > > IIRC,
>  bison and flex were both needed to *build* gcc for the avr target on > mingw,
>  not just to develop / modify. I don't know if this is a general case. > Eric
>  Weddington
> 
> This shouldn't be required for released versions of GCC in any
> configuration.  What version of GCC were you using?  Are you sure your
> timestamps were correct?

My bad. I checked last night and you're correct. I don't need bison / flex for 
GCC *releases*, but they are needed to build the weekly snapshots. So I didn't 
interpret your description correctly because I don't necessarily develop or 
modify GCC. So perhaps this?:

To develop/modify/build snapshots of GCC (all of the above tools plus):

Sorry for my confusion.

Eric Weddington

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Fri, 30 May 2003, E. Weddington wrote:
> My bad. I checked last night and you're correct. I don't need bison /
> flex for GCC *releases*, but they are needed to build the weekly
> snapshots.

I consider this a bug, and will happily consider patches that address
this (without requiring a full build as part of snapshot generation).

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Sat, 31 May 2003, Gerald Pfeifer wrote:

> On Fri, 30 May 2003, E. Weddington wrote:
> > My bad. I checked last night and you're correct. I don't need bison /
> > flex for GCC *releases*, but they are needed to build the weekly
> > snapshots.
> 
> I consider this a bug, and will happily consider patches that address
> this (without requiring a full build as part of snapshot generation).

They will likely also require manual timestamp adjustments (not gcc_update
--touch, that only deals with files in CVS) after applying patches between
snapshots, otherwise files may inconsistently get regenerated / not get
regenerated with different versions of Bison causing build failures.  
(The problem can exist for releases, but it's much rarer for parsers to
change between point releases.)  So you'd need - at least - to arrange for
diffs to undergo a topological sort (using an extended list of
dependencies that covers files generated for snapshots as well as those in
CVS).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[E. Weddington]

On 31 May 2003 at 18:04, Joseph S. Myers wrote:

> On Sat, 31 May 2003, Gerald Pfeifer wrote:
> 
> > On Fri, 30 May 2003, E. Weddington wrote:
> > > My bad. I checked last night and you're correct. I don't need bison /
> > > flex for GCC *releases*, but they are needed to build the weekly
> > > snapshots.
> > 
> > I consider this a bug, and will happily consider patches that address
> > this (without requiring a full build as part of snapshot generation).

Why would you consider this a bug?
 
> They will likely also require manual timestamp adjustments (not gcc_update
> --touch, that only deals with files in CVS) after applying patches between
> snapshots, otherwise files may inconsistently get regenerated / not get
> regenerated with different versions of Bison causing build failures.  
> (The problem can exist for releases, but it's much rarer for parsers to
> change between point releases.)  So you'd need - at least - to arrange for
> diffs to undergo a topological sort (using an extended list of
> dependencies that covers files generated for snapshots as well as those in
> CVS).

Why not just explicitly state that these tools (bison/flex) are required if 
building weekly snapshots?


If you still consider this a bug, do you want me to go ahead fill out a PR for 
this?

Eric

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Mon, 2 Jun 2003, E. Weddington wrote:
>>>> My bad. I checked last night and you're correct. I don't need bison /
>>>> flex for GCC *releases*, but they are needed to build the weekly
>>>> snapshots.
>>> I consider this a bug, and will happily consider patches that address
>>> this (without requiring a full build as part of snapshot generation).
> Why would you consider this a bug?

Because snapshots should be easy to use and require few prerequisites,
similar to releases. IMHO.

> Why not just explicitly state that these tools (bison/flex) are required
> if building weekly snapshots?

We already do that.  Still, it would be nice to make snapshots "cheaper"
to use.

> If you still consider this a bug, do you want me to go ahead fill out a
> PR for this?

Please don't.  You're right in that it's actually more of a wish or
enhancement request than a bug.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
> At the GCC BOF where topics relating to process and maintenence were
> discussed, one of the issues was tools (and acceptable versions) that
> are necessary for building and/or modifying GCC.

Excellent.

> ------------------------------------------------------
> gzip version 1.2.4 (or later) or
> bzip2 version ??? (or later)

bzip 1.0 and 1.0.1 would be sufficient, but bzip2 1.0.2 solved security
issues and other bugs and is widely deployed, so I'd specify that.

Though, in fact, given that these two programs will need to remain compatible
by design, do we really need to specify versions?

> Necessary to uncompress gcc tar files when source code is obtained via
> FTP mirror sites.

s/gcc/GCC/

> ------------------------------------------------------
> expect version ???
> tcl version ???
> dejagnu version ???
>
> Necessary to run the GCC testsuite.

Please put this information into doc/install.texi (or update the one
already there, respectively) only, to avoid duplication which will
lead to inconsistency in the long term.

(That's one of the problems we still have with the Java web pages, for
example, though I'm working on that.)

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
 > 
 > On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
 > > At the GCC BOF where topics relating to process and maintenence were
 > > discussed, one of the issues was tools (and acceptable versions) that
 > > are necessary for building and/or modifying GCC.
 > 
 > Excellent.
 > 
 > > ------------------------------------------------------
 > > gzip version 1.2.4 (or later) or
 > > bzip2 version ??? (or later)
 > 
 > bzip 1.0 and 1.0.1 would be sufficient, but bzip2 1.0.2 solved security
 > issues and other bugs and is widely deployed, so I'd specify that.
 > 
 > Though, in fact, given that these two programs will need to remain compatible
 > by design, do we really need to specify versions?
 > 
 > > Necessary to uncompress gcc tar files when source code is obtained via
 > > FTP mirror sites.
 > 
 > s/gcc/GCC/

Thanks, I made the above changes.


 > > ------------------------------------------------------
 > > expect version ???
 > > tcl version ???
 > > dejagnu version ???
 > >
 > > Necessary to run the GCC testsuite.
 > 
 > Please put this information into doc/install.texi (or update the one
 > already there, respectively) only, to avoid duplication which will
 > lead to inconsistency in the long term.
 > Gerald

OK.  Where in install.texi should it put it?

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Thu, 29 May 2003, Kaveh R. Ghazi wrote:
>>> expect version ???
>>> tcl version ???
>>> dejagnu version ???
>> Please put this information into doc/install.texi (or update the one
>> already there, respectively) only, to avoid duplication which will
>> lead to inconsistency in the long term.
> OK.  Where in install.texi should it put it?

We already have the following paragraph in the part concerning testing,
so I think it's best (and easiest for you <g>) to add any additional
information related to testing there:

  Second, you must have the testing tools installed.  This includes
  @uref{http://www.gnu.org/software/dejagnu/,,DejaGnu} 1.4.2 (or later),
  Tcl, and Expect; the DejaGnu site has links to these.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Documenting tools necessary for GCC [draft]

[Ranjit Mathew]

>>>>expect version ???
>>>>tcl version ???
>>>>dejagnu version ???
>>>
>>>Please put this information into doc/install.texi (or update the one
>>>already there, respectively) only, to avoid duplication which will
>>>lead to inconsistency in the long term.
>>
>>OK.  Where in install.texi should it put it?
> 
> 
> We already have the following paragraph in the part concerning testing,
> so I think it's best (and easiest for you <g>) to add any additional
> information related to testing there:
> 
>   Second, you must have the testing tools installed.  This includes
>   @uref{http://www.gnu.org/software/dejagnu/,,DejaGnu} 1.4.2 (or later),
>   Tcl, and Expect; the DejaGnu site has links to these.

A bit late in the thread, but I must point out that
at least for testing the libjava testsuite we need
DejaGNU 1.4.3 or later:

    http://gcc.gnu.org/ml/java/2003-06/msg00132.html

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Thu, Jun 12, 2003 at 03:55:36PM +0530, Ranjit Mathew wrote:
> A bit late in the thread, but I must point out that
> at least for testing the libjava testsuite we need
> DejaGNU 1.4.3 or later:
> 
>     http://gcc.gnu.org/ml/java/2003-06/msg00132.html

I had been using 1.4.1 without problems up until now.  And the message
you link to is you saying you think that 1.4.3 should be required.  Have
the GCJ people decided that 1.4.3 *is* required?

Re: Documenting tools necessary for GCC [draft]

[Tom Tromey]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

Joe> I had been using 1.4.1 without problems up until now.  And the message
Joe> you link to is you saying you think that 1.4.3 should be required.  Have
Joe> the GCJ people decided that 1.4.3 *is* required?

Ranjit ran into a bug in 1.4.2 preventing him from running the libgcj
test suite.  This is in the quoted part of the message he linked to.
Original report here:

http://gcc.gnu.org/ml/java/2003-06/msg00117.html

Tom

Re: Documenting tools necessary for GCC [draft]

[Gerald Pfeifer]

On Thu, 12 Jun 2003, Tom Tromey wrote:
>Joe> I had been using 1.4.1 without problems up until now.
> Ranjit ran into a bug in 1.4.2 preventing him from running the libgcj
> test suite.  This is in the quoted part of the message he linked to.
> Original report here:
>
> http://gcc.gnu.org/ml/java/2003-06/msg00117.html

So, I see two possibilities:

 a) require 1.4.1 or 1.4.3 (and later), or
 b) require 1.4.3 (and later).

I'll implement whatever you all agree on, but for the sake of simplicity
and because there probably _was_ a reason we currently have 1.4.2 listed
there, I'd prefer b).

Is this fine with you (especially Joe)?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Fri, Jun 13, 2003 at 01:19:45AM +0200, Gerald Pfeifer wrote:
> On Thu, 12 Jun 2003, Tom Tromey wrote:
> >Joe> I had been using 1.4.1 without problems up until now.
> > Ranjit ran into a bug in 1.4.2 preventing him from running the libgcj
> > test suite.  This is in the quoted part of the message he linked to.
> > Original report here:
> >
> > http://gcc.gnu.org/ml/java/2003-06/msg00117.html
> 
> So, I see two possibilities:
> 
>  a) require 1.4.1 or 1.4.3 (and later), or
>  b) require 1.4.3 (and later).
> 
> I'll implement whatever you all agree on, but for the sake of simplicity
> and because there probably _was_ a reason we currently have 1.4.2 listed
> there, I'd prefer b).
> 
> Is this fine with you (especially Joe)?

Do we know whether 1.4.1 has the bug?  Is it only in 1.4.2?

Re: Documenting tools necessary for GCC [draft]

[Ranjit Mathew]

[CC'ing Rob to confirm that this is DejaGNU regression in 1.4.2
fixed in 1.4.3]


>>>Joe> I had been using 1.4.1 without problems up until now.
>>>Ranjit ran into a bug in 1.4.2 preventing him from running the libgcj
>>>test suite.  This is in the quoted part of the message he linked to.
>>>Original report here:
>>>
>>>http://gcc.gnu.org/ml/java/2003-06/msg00117.html
>>
>>So, I see two possibilities:
>>
>> a) require 1.4.1 or 1.4.3 (and later), or
>> b) require 1.4.3 (and later).
>>
>>I'll implement whatever you all agree on, but for the sake of simplicity
>>and because there probably _was_ a reason we currently have 1.4.2 listed
>>there, I'd prefer b).
>>
>>Is this fine with you (especially Joe)?
> 
> 
> Do we know whether 1.4.1 has the bug?  Is it only in 1.4.2?

In 1.4.2, the "FOO=BAR" parsing code in runtest.exp was
moved into the first pass through the command line but
was not taken care of in the second pass. This is what
causes the error. So both 1.4.1 and 1.4.3 are OK but not
1.4.2.

You can check if your (unpatched) version is OK by running

    runtest FOO=bar --version

This should set the Tcl variable FOO to bar and not
cause an error.

In fact this seems to be one of the more commonly
asked questions on the dejagnu lists:

http://mail.gnu.org/archive/html/dejagnu/2002-04/msg00012.html
http://mail.gnu.org/archive/html/bug-dejagnu/2002-04/msg00005.html
http://mail.gnu.org/archive/html/bug-dejagnu/2002-09/msg00006.html

etc.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: Documenting tools necessary for GCC [draft]

[Rob Savoye]

On Fri, Jun 13, 2003 at 10:45:44AM +0530, Ranjit Mathew wrote:
> [CC'ing Rob to confirm that this is DejaGNU regression in 1.4.2
> fixed in 1.4.3]

  This is fixed in 1.4.3.

> >>and because there probably _was_ a reason we currently have 1.4.2 listed
> >>there, I'd prefer b).

  It was probably listed as 1.4.2 only cause somebody didn't notice the 1.4.3
release. :-)

	- rob -

Re: Documenting tools necessary for GCC [draft]

[Mike Stump]

On Thursday, May 29, 2003, at 10:27 AM, Kaveh R. Ghazi wrote:
> autogen version ???
> guile version ???
>
> Necessary when modifying fixinc/inclhack.def or fixinc/*.tpl to
> regenerate fixinc/fixincl.x.

And for Makefile.def/Makefile.tpl

> ------------------------------------------------------
> makeinfo version 4.2 (or later)

I have 4.2 on darwin, and it dumps for me with mainline.  I don't know 
of a version that works, but I have a patch to the .texi files to make 
them compatible with 4.2, that patch is in the 3.3 release.

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Mike Stump <mrs@apple.com>
 > 
 > > makeinfo version 4.2 (or later)
 > 
 > I have 4.2 on darwin, and it dumps for me with mainline.


I think the configure script checks for 4.2, so we should make it work
with that version.



 > I don't know of a version that works, but I have a patch to the
 > .texi files to make them compatible with 4.2, that patch is in the
 > 3.3 release.

Any reason you haven't forward-ported it to mainline?

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Mike Stump]

On Thursday, May 29, 2003, at 06:04 PM, Kaveh R. Ghazi wrote:
>> I don't know of a version that works, but I have a patch to the
>> .texi files to make them compatible with 4.2, that patch is in the
>> 3.3 release.
>
> Any reason you haven't forward-ported it to mainline?

I would like to, but don't have an OK for it.  At least one person 
wanted to see makeinfo -html fixed and then depend upon the new version 
of that tool for 3.4.

Personally, I don't like revlocking, if it can be avoided, and the 4 
extra hacking lines to avoid the problem don't seem to be overly 
burdensome.

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Thu, 29 May 2003, Kaveh R. Ghazi wrote:

>  > I don't know of a version that works, but I have a patch to the
>  > .texi files to make them compatible with 4.2, that patch is in the
>  > 3.3 release.
> 
> Any reason you haven't forward-ported it to mainline?

It's not the Right solution; it's a temporary kludge.  The proper solution
- as a "good cooperating member of the free software community" (to merge
two phrases from contributewhy.html) - must involve reporting the problem
to the Texinfo maintainers (generally very responsive to problems found in
connection with GCC) and having them identify and fix it - then adjusting
required versions if it turns out that the problem may affect info (not
just HTML) generation on some systems.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[David O'Brien]

On Thu, May 29, 2003 at 01:27:41PM -0400, Kaveh R. Ghazi wrote:
> To build GCC:
> 
> ------------------------------------------------------
> A working Bourne (or compatible) shell, or
> GNU bash version 2.??? (or later)
> 
> Necessary when running configure because some /bin/sh shells have bugs
> or disastrous corner-case performance problems.  Set CONFIG_SHELL in
> your environment to your "good" shell prior to running configure/make.
> Sometimes /bin/ksh is sufficient, sometimes it isn't.  See the
> host/target specific instructions for your platform, or use bash to be
> sure.
> ------------------------------------------------------

I'd really like this to state a POSIX compliant shell, and list the exact
POSIX spec (and year) that OS's must adhere to.

> To develop/modify GCC (all of the above tools plus):
> 
> ------------------------------------------------------
> autoconf version 2.13 (NO earlier or later versions)
> GNU m4 version 1.4 (or later)
> 
> Necessary when modifying configure.in, aclocal.m4, etc to regenerate
> configure and config.in files
> ------------------------------------------------------

Why can't GCC come out of the dark ages and state autoconf 2.5x?


> ------------------------------------------------------
> GNU Bison version 1.28 (or later)
> Flex version 2.5.4 (or later)
> 
> Necessary when modifying *.y (bison) or *.l (flex).
> 
> Necessary to build GCC during development because the generated output
> files are not included in the cvs repository.  They are included in
> releases.
> ------------------------------------------------------

More so than any Gmake concerns, the BSD's need the basic languages:
C/C++/FORTRAN to be buildable with YACC rather than Bison.  I know Java
requires Bison, and that is fine from the BSD POV.

-- 
-- David  (obrien@FreeBSD.org)

Re: Documenting tools necessary for GCC [draft]

[Andreas Jaeger]

"David O'Brien" <obrien@FreeBSD.org> writes:

> Why can't GCC come out of the dark ages and state autoconf 2.5x?

It does not work yet - but we decided to move forward on this.  The
current list states the current situation - and not what's needs to be
done...

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > More so than any Gmake concerns, the BSD's need the basic languages:
 > C/C++/FORTRAN to be buildable with YACC rather than Bison.  I know
 > Java requires Bison, and that is fine from the BSD POV.
 > -- David  (obrien@FreeBSD.org)

I'll repeat here what I mentioned to you in private email.  Namely
that:

1.  Neither C++ nor fortran contain a yacc/bison parser, so that's not
    a problem.

2.  The long term plan I heard from Mark was to merge the C parser
    (and I assume objc) into the hand written one from C++, so
    possibly needing bison there will go away too.

3.  There remains intl/plural.y which is imported so I suspect it'll
    remain YACCable.

4.  The gengtype yacc stuff IMO is unlikely to need changing.

So I suspect you're safe on this issue.

However I was not aware that the existing files supported anything
other than bison, so it may simply be luck that it works today.  I
don't know for sure.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Joe Buck]

On Fri, May 30, 2003 at 04:38:27PM -0400, Kaveh R. Ghazi wrote:
> 2.  The long term plan I heard from Mark was to merge the C parser
>     (and I assume objc) into the hand written one from C++, so
>     possibly needing bison there will go away too.

Right, and then hopefully get Objective-C++ contributions from Apple moved
into that as well.

> However I was not aware that the existing files supported anything
> other than bison, so it may simply be luck that it works today.  I
> don't know for sure.

In the old days, Cygnus used to use byacc for their builds, and supply
byacc rather than bison to their customers.  This was done because
originally the bison parser skeleton was GPLed, meaning that all bison
output had to be licensed under the GPL.  The FSF changed this with bison
1.24; bison output no longer must be copylefted (though of course bison
itself is still under the GPL).  Because of this, byacc has worked for a
long time, not by luck but by design.

The Java front end is newer work, though, and evidently uses some
bison-specific features.

Re: Documenting tools necessary for GCC [draft]

[Matt Austern]

On Friday, May 30, 2003, at 02:54  PM, Joe Buck wrote:

> On Fri, May 30, 2003 at 04:38:27PM -0400, Kaveh R. Ghazi wrote:
>> 2.  The long term plan I heard from Mark was to merge the C parser
>>     (and I assume objc) into the hand written one from C++, so
>>     possibly needing bison there will go away too.
>
> Right, and then hopefully get Objective-C++ contributions from Apple 
> moved
> into that as well.

We certainly are planning to contribute ObjC++.  It'll be a fair amount
of work moving it to the new parser, of course; I can't make any 
specific
promises about when this work will be finished.

			--Matt

Re: Documenting tools necessary for GCC [draft]

[Zack Weinberg]

"David O'Brien" <obrien@FreeBSD.org> writes:

> I'd really like this to state a POSIX compliant shell, and list the exact
> POSIX spec (and year) that OS's must adhere to.

Not good enough.  The POSIX shell and make specifications were not
written with the aim of making it possible to write portable shell
scripts or makefiles.  They were written with the aim of making it
possible for all the Unix(TM) vendors participating in the process
to claim compliance with the standard without changing anything in
their shipped operating systems.  That means you can find blatant
semantic or even syntactic incompatibilities between shells or Make
implementations that claim to be POSIX compliant.  Examples have
been posted here in the past.

This MAY have been addressed in the 2001 revision, but I don't trust
that to be the case, and it's moot anyway; the 2001 revision is far
too new to be our baseline.

> Why can't GCC come out of the dark ages and state autoconf 2.5x?

Everyone who has tried to date has tripped over incompatibilities of
documented behavior between 2.13 and 2.5x and given up.  We agreed at
the BOF to bite the bullet and make it work, but that will take time.

zw

Re: Documenting tools necessary for GCC [draft]

[Fergus Henderson]

On 01-Jun-2003, Zack Weinberg <zack@codesourcery.com> wrote:
> "David O'Brien" <obrien@FreeBSD.org> writes:
> 
> > I'd really like this to state a POSIX compliant shell, and list the exact
> > POSIX spec (and year) that OS's must adhere to.
> 
> Not good enough.  [...] you can find blatant
> semantic or even syntactic incompatibilities between shells or Make
> implementations that claim to be POSIX compliant.

Sure, but you can find blatant incompatibilities between different C
compilers too... why is writing shell code or make code that conforms
to the POSIX spec any harder than writing C code which conforms to
the C standard?

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

Re: Documenting tools necessary for GCC [draft]

[Zack Weinberg]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 01-Jun-2003, Zack Weinberg <zack@codesourcery.com> wrote:
>> "David O'Brien" <obrien@FreeBSD.org> writes:
>> 
>> > I'd really like this to state a POSIX compliant shell, and list the exact
>> > POSIX spec (and year) that OS's must adhere to.
>> 
>> Not good enough.  [...] you can find blatant
>> semantic or even syntactic incompatibilities between shells or Make
>> implementations that claim to be POSIX compliant.
>
> Sure, but you can find blatant incompatibilities between different C
> compilers too... why is writing shell code or make code that conforms
> to the POSIX spec any harder than writing C code which conforms to
> the C standard?

The C standard gives an implementor far less wiggle room.

zw

Re: Documenting tools necessary for GCC [draft]

[Joseph S. Myers]

On Sun, 1 Jun 2003, Zack Weinberg wrote:

> Not good enough.  The POSIX shell and make specifications were not
> written with the aim of making it possible to write portable shell
> scripts or makefiles.  They were written with the aim of making it

POSIX make is fairly useless, but the POSIX shell specification
essentially documented ksh (which is what e.g. Solaris uses as
/usr/xpg4/bin/sh).  It is a usable environment for writing portable shell
scripts and far better to specify that than to attempt to support
derivatives of the original Bourne shell.  The POSIX specification of the
shell is also much clearer than most other documents that attempt to
explain the Unix shell.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Documenting tools necessary for GCC [draft]

[Zack Weinberg]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> POSIX make is fairly useless, but the POSIX shell specification
> essentially documented ksh (which is what e.g. Solaris uses as
> /usr/xpg4/bin/sh).  It is a usable environment for writing portable shell
> scripts and far better to specify that than to attempt to support
> derivatives of the original Bourne shell.  The POSIX specification of the
> shell is also much clearer than most other documents that attempt to
> explain the Unix shell.

I mostly agree, but there are still areas which can cause trouble.
For instance, there is nothing in POSIX saying that IFS must be set to
<space><tab><newline> on startup, ignoring any value in the
environment, but all our configure scripts break if the shell doesn't
do that.  (Autoconf 2.5x may have fixed this.)  This is *not* a
hypothetical problem - the Debian ash maintainer at one point tried to
have it be unset on startup, relented only after a ferocious argument,
and insisted on reserving the right to change it again in the future.

Another good example is the insane removal of support for obsolete
command line syntax in the 2001 revision, for things like "sort +1".
And didn't someone say upthread that AIX /bin/ksh had performance
problems with libstdc++-v3/configure?

zw

Re: Documenting tools necessary for GCC [draft]

[David O'Brien]

On Sun, Jun 01, 2003 at 12:03:36AM -0700, Zack Weinberg wrote:
> "David O'Brien" <obrien@FreeBSD.org> writes:
> 
> > I'd really like this to state a POSIX compliant shell, and list the exact
> > POSIX spec (and year) that OS's must adhere to.
> 
> Not good enough.  The POSIX shell and make specifications were not
> written with the aim of making it possible to write portable shell
> scripts or makefiles.

The I would like to have the FreeBSD /bin/sh explicitly stated as a shell
that GCC must bootstrap using.  Bash'isms & Linux'isms should be kept out
of the bourne code.  I was hoping we could simply say "POSIX shell", but
if that won't do, then I'd like to see some shell implementations
explicitly listed as supported.

-- 
-- David  (obrien@FreeBSD.org)

Re: Documenting tools necessary for GCC [draft]

[Zack Weinberg]

"David O'Brien" <obrien@FreeBSD.org> writes:

> On Sun, Jun 01, 2003 at 12:03:36AM -0700, Zack Weinberg wrote:
>> "David O'Brien" <obrien@FreeBSD.org> writes:
>> 
>> > I'd really like this to state a POSIX compliant shell, and list the exact
>> > POSIX spec (and year) that OS's must adhere to.
>> 
>> Not good enough.  The POSIX shell and make specifications were not
>> written with the aim of making it possible to write portable shell
>> scripts or makefiles.
>
> The I would like to have the FreeBSD /bin/sh explicitly stated as a shell
> that GCC must bootstrap using.  Bash'isms & Linux'isms should be kept out
> of the bourne code.  I was hoping we could simply say "POSIX shell", but
> if that won't do, then I'd like to see some shell implementations
> explicitly listed as supported.

I'd be fine with that.

zw

RE: Documenting tools necessary for GCC [draft]

[Bruce Korb]

> We could say this, but there wouldn't be much point.  We use autoconf,
> and autoconf doesn't make use of any "twentieth century shell" features
> such as functions.

I do believe that functions are now okay for the 21st century auto*.
'bout time.

------------------------------------------------------
autogen version 5.5.4
guile version 1.4.1

Necessary to:

regenerate fixinc/fixincl.x from
   fixinc/inclhack.def and fixinc/*.tpl
run the fixinc/ directory make check
regenerate the top level Makefile.am's from
   Makefile.tpl and Makefile.def

------------------------------------------------------

(you could probably get away with earlier versions than
5.5.4, but the Makefile.tpl could contain some of the feature
creep since fixincl.tpl was written...Makefile.tpl is also
under active development.)

At some point, Guile 1.6 will be required because they are
in the process of disposing of the gh_* interface.  AutoGen
currently uses that.

And, no, AutoGen is not part of Guile, nor does AutoGen
ship with Guile.  You gotta get both.

------------------------------------------------------

RE: Documenting tools necessary for GCC [draft]

[Kaveh R. Ghazi]

 > From: Bruce Korb <bkorb@veritas.com>
 > 
 > ------------------------------------------------------
 > autogen version 5.5.4
 > guile version 1.4.1
 > 
 > Necessary to:
 > 
 > regenerate fixinc/fixincl.x from
 >    fixinc/inclhack.def and fixinc/*.tpl
 > run the fixinc/ directory make check
 > regenerate the top level Makefile.am's from
 >    Makefile.tpl and Makefile.def

Thanks, got it.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Documenting tools necessary for GCC [draft]

[Robert Dewar]

> We only said that we would support Posix-compliant makes.  I'm not sure
> about Irix.  I know that some of the issues on some platforms were because
> of broken vendor makes.

I will not declare anything broken, because you never know what the 
spec is :-)

But for sure let's just say that SGI has critically different semantics in
certain areas compared to other versions of make :-)

RE: Documenting tools necessary for GCC [draft]

[Nathanael Nerode]

Bruce said:
> ------------------------------------------------------
> autogen version 5.5.4
> guile version 1.4.1
> 
> Necessary to:
> 
> regenerate fixinc/fixincl.x from
>    fixinc/inclhack.def and fixinc/*.tpl
> run the fixinc/ directory make check
> regenerate the top level Makefile.am's from
That's "The top level Makefile.in".  No automake at the top level (there 
are almost no actual files to deal with, so automake is an unnecessary 
complication).
>    Makefile.tpl and Makefile.def
> 
> ------------------------------------------------------
> 
> (you could probably get away with earlier versions than
> 5.5.4, but the Makefile.tpl could contain some of the feature
> creep since fixincl.tpl was written...Makefile.tpl is also
> under active development.)
That it is.  I don't think it contains any feature creep; all I've used 
so far are IF/ELSE, FOR, and plain old substitutions.  (Albeit lots and 
lots of those, nested, which is why I'm using AutoGen.)  But it might in 
the future.  :-)

I wouldn't be at all surprised if any AutoGen version in the 5.x series 
worked for Makefile.tpl.  (Nothing earlier, obviously!)

> At some point, Guile 1.6 will be required because they are
> in the process of disposing of the gh_* interface.  AutoGen
> currently uses that.
> 
> And, no, AutoGen is not part of Guile, nor does AutoGen
> ship with Guile.  You gotta get both.

Makefile.tpl doesn't use anything guile-version-specific at the moment, 
so it simply requires whatever version AutoGen requires.

--Nathanael

RE: Documenting tools necessary for GCC [draft]

[Bruce Korb]

Nathanael wrote:
> Bruce said: 
> [[...]]
>         regenerate the top level Makefile.am's from
> 
> That's "The top level Makefile.in". No automake at the top level
> (there are almost no actual files to deal with,
> so automake is an unnecessary complication). 

That's what I get for typing off the top of my head....

>         (you could probably get away with earlier versions than
>         5.5.4, but the Makefile.tpl could contain some of the feature
>         creep since fixincl.tpl was written...Makefile.tpl is
>         under active development.)
> 
> That it is. I don't think it contains any feature creep; all I've used so far
> are IF/ELSE, FOR, and plain old substitutions. (Albeit lots and lots of those,
> nested, which is why I'm using AutoGen.) But it might in the future. :-)

I'm trying to sell you on using [= FOR name IN list ... =]
which showed up in 5.4.  Problem is, issues showed up in 5.4 that
weren't fully ironed out until 5.5.3/4.  :-}  Ergo, may as well
encourage 5.5.4....

RE: Guile.  AutoGen requires the 1.4.1 interface or later.
Even though the gh_* interface is documented as the preferred
user interface for the 1.4.x series, it is deprecated in the
next (1.6) release series and intended to be retired RSN.
They are making several incompatible changes to the interface,
even within the gh_* interface.  :(

Re: Documenting tools necessary for GCC [draft]

[Robert Dewar]

> The C standard gives an implementor far less wiggle room.

Basically the C standard was written to enable the writing of portable
code, and required C compilers to conform to a common functional spec
for a large part of the language.

The Posix spec is not written with this in mind, there are huge and
significant unspecified functionalities (for example, POSIX threads
does not even bother to precisely define the dispatching model).
As Zack says, the point of the POSIX spec was to create a common
set of functionalities. If you have a POSIX compliant technology,
then the idea is that you are guaranteed that you have an appropriate
basic set of functions, but you are definitely not guaranteed that
your posix code from another system will port unchanged. 

Yes, you can carefully write to the common guaranteed subset, but this
is not particularly the intention of the standard, and is in practice
very difficult to do.

Re: Documenting tools necessary for GCC [draft]

[Fergus Henderson]

On 01-Jun-2003, Robert Dewar <dewar@gnat.com> wrote:
> > The C standard gives an implementor far less wiggle room.
> 
> Basically the C standard was written to enable the writing of portable
> code, and required C compilers to conform to a common functional spec
> for a large part of the language.
> 
> The Posix spec is not written with this in mind,

The name POSIX (_Portable_ Operating System Interface)
certainly suggests otherwise.

I understand that the Posix spec aimed to standardize the common features
of existing Unix implementations, which had been diverging for quite
some time.  But this is not so different from the development of the
C standard.

> there are huge and significant unspecified functionalities

The same is true of C.

> (for example, POSIX threads
> does not even bother to precisely define the dispatching model).

So Posix doesn't define the order of evaluation of code in different threads?
C doesn't define the order of evaluation of arguments to function calls.
In addition, almost any use of signal() results in undefined behaviour,
and some argue that the same is true of "volatile".  There are many
other examples.

> you are definitely not guaranteed that
> your posix code from another system will port unchanged. 

Neither are you guaranteed that your C code from another system will
port unchanged.

> Yes, you can carefully write to the common guaranteed subset, but this
> is not particularly the intention of the standard, and is in practice
> very difficult to do.

Writing portable C code is very difficult too... and yet people manage it.

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

Re: Documenting tools necessary for GCC [draft]

[Dan Kegel]

Thanks for taking this on.  Can you keep the current draft at some URL for
reference?

Also, can you address whether and how to regenerate */aclocal.m4?
I have a feeling those are hand-generated only now, and
using any version of automake's aclocal command to generate them
is an error, but I don't have evidence to back this up.

Thanks,
Dan

Re: Documenting tools necessary for GCC [draft]

[Phil Edwards]

On Mon, Jun 02, 2003 at 11:48:54AM -0700, Dan Kegel wrote:
> 
> Also, can you address whether and how to regenerate */aclocal.m4?
> I have a feeling those are hand-generated only now, and
> using any version of automake's aclocal command to generate them
> is an error, but I don't have evidence to back this up.

Not exactly.

    if <an acinclude.m4 file exists>
    then
        <automake is being used; use aclocal(1) to generate aclocal.m4,
         which will contain acinclude.m4 plus things needed by automake>
    else
        <only autoconf is being used; aclocal.m4 is written (not generated)
         by hand>
    endif

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Documenting tools necessary for GCC [draft]

[Dan Kegel]

Phil Edwards wrote:
>     if <an acinclude.m4 file exists>
>     then
>         <automake is being used; use aclocal(1) to generate aclocal.m4,
>          which will contain acinclude.m4 plus things needed by automake>
>     else
>         <only autoconf is being used; aclocal.m4 is written (not generated)
>          by hand>
>     endif

Thanks!  Then it's just a question of which automake's aclocal to use.
Looks like it's usually automake-1.4
(ftp://ftp.gnu.org/gnu/automake/automake-1.4.tar.gz ?)
but for libstdc++-v3, automake-1.4-p6 is used
(ftp://ftp.gnu.org/gnu/automake/automake-1.4-p6.tar.gz ?):

~/gcc-3.3$ grep 'generated auto' */aclocal.m4
boehm-gc/aclocal.m4:dnl aclocal.m4 generated automatically by aclocal 1.4
fastjar/aclocal.m4:dnl aclocal.m4 generated automatically by aclocal 1.4
libffi/aclocal.m4:dnl aclocal.m4 generated automatically by aclocal 1.4
libjava/aclocal.m4:dnl aclocal.m4 generated automatically by aclocal 1.4
libstdc++-v3/aclocal.m4:dnl aclocal.m4 generated automatically by aclocal 1.4-p6
zlib/aclocal.m4:dnl aclocal.m4 generated automatically by aclocal 1.4


BTW, it looks like the autoconf used to generate gcc-3.3/gcc/configure
was ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.13.tar.gz plus the mawk patch, e.g.
http://pkgcvs.turbolinux.co.jp/centro/index.cgi/~checkout~/autoconf/2.13/Attic/autoconf-2.13-mawk.patch?rev=1.1&content-type=text/plain&hideattic=0
At least, when I used those together and ran autoconf, I got a configure script identical to the one that was shipped.
- Dan

Re: Documenting tools necessary for GCC [draft]

[Andreas Schwab]

Phil Edwards <phil@jaj.com> writes:

|> On Mon, Jun 02, 2003 at 11:48:54AM -0700, Dan Kegel wrote:
|> > 
|> > Also, can you address whether and how to regenerate */aclocal.m4?
|> > I have a feeling those are hand-generated only now, and
|> > using any version of automake's aclocal command to generate them
|> > is an error, but I don't have evidence to back this up.
|> 
|> Not exactly.
|> 
|>     if <an acinclude.m4 file exists>
|>     then
|>         <automake is being used; use aclocal(1) to generate aclocal.m4,
|>          which will contain acinclude.m4 plus things needed by automake>

acinclude.m4 is not a prerequisite for automake, aclocal also collects
macros from all *.m4 files that it find in its search path.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."