Re: Suggestion for removing flex/bison as a dependancy

["J.C. Pizarro" <jcpiza at gmail dot com>]

On 2007/11/26, Karthik Kumar <karthikkumar@gmail.com> wrote:
> Hi,
>
>
> On Nov 27, 2007 12:13 AM, J.C. Pizarro <jcpiza@gmail.com> wrote:
> > On Mon, Nov 26, 2007, Karthik Kumar wrote:
> > > I would like to propose a set of diffs to enable compilation of gcc
> > > without requiring flex/bison. I feel that this would greatly benefit
> > > the variety of users building gcc.
> >
> > Dear Karthik Kumar, why not flex/bison? It's bad idea not using them.
>
> I'm not saying we don't use flex/bison. I am only saying we can remove
> that as a build dependancy; Many people have to use specific versions
> of lex (flex) and yacc (bison) if they wish to compile gcc. All
> directories which have configure scripts also have their autoconf
> files (configure.ac) in the tree. And many directories which have
> Makefile.in have Makefile.am as well. It is generally a good idea for
> the user to keep the autotools as well; But there is no need to use
> those if the configure and Makefile.in files are already there.
> Besides, taking a look at the tree, libintl and libjava have processed
> .y files. I only suggest that we keep the C versions of these files in
> the tree as well.
>
> >
> > The tools flex/bison are required as any tool
> > ( e.g. patch, diff, binutils, sed, bash, gzip, cvs, m4, etc. ) and
> > they are smaller executables to be stored in a CD.
> >
> > The generated files from flex/bison are a lot of "trashing hexadecimals" that
> > don't must to be commited to any cvs/svn/git/hg because it consumes
> > a lot of diskspace for only a modification of few lines of flex/bison sources.
>
> The configure/Makefile.in scripts are significantly large as well.

I hate considering temporary files as sources of the tree. They aren't sources.

It's good idea to remove ALL generated files from sources:

A) generated *.c, *.h from lex/bison sources *.l/*.y
B) generated not-handwritten configure, makefile, aclocal.m4, config.h.in,
     makefile.in from the configure.ac and makefile.am sources.
      [the handwritten configure and makefile have to be rewritten to *.ac/*.am]
C) generated binary objects *.class, *.o, *.a, *.so, ...
D) generated *.c, *.h, *.cpp, *.hpp,  ... from *.java
E) any generated from any available source by available tool.

The only exception is when the project need a bootstrapping system.

See to understand http://en.wikipedia.org/wiki/GNU_build_system easy!

So, the cvs/svn/git/hg repositories of sources will be "small and clean"
without "trashing generated files, hexadecimals, ..."

This recommendation is an advantage to navigate by web to clean
cvs/svn/git/hg repositories. In another case, it's an inconvenient.

J.C.Pizarro