Re: egcs-970828: Some nits

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message <199709040329.XAA05067@sleipnir.valparaiso.cl>you write:
  > Yep, the specs file is correctly installed.
Very strange since neither Jim nor myself can figure out how/why 
a gcc-2.7 vintage compiler could die in this manner.

It is interesting to note that his has happened only for linux folks.
Makes me wonder if there's some braindamage going on in one of linux
config files from gcc-2.7.

  > OTOH (and this is more serious, IMHO) is the problem that make builds _all_
  > languages for the first stage. Happened to me with sparc-sun-solaris2.5.1,
  > gcc-2.7.2.3; but not here on Linux for egcs-970901 built with egcs-970828.
  > Not nice (couple hours grinding away...), might blow up in your face with
  > non-gcc compilers.
Yes, we're aware of the problem.  You can stop this by using LANGUAGES=c
when building.

I'm thinking about adding a "bootstrap" target at the toplevel that heads
into the gcc tree first, does a 3stage on gcc, then builds the rest of
the tree.

Regardless, this is something we know has to be fixed before the first
public release.  Since nobody else is working on it, I'll probably just
implement my solution for the next snapshot since it's important.

  > > I think the way to do this is to use the --prefix option to install the
  > > binaries into a different location.  egcs  is _not_ gcc-2.8.
  > 
  > You are right.
Another alternative is to go ahead and install it without the --prefix and
use -V to select different versions of the compiler.

  > OK, I understand that. But the ChangeLog files I see start rather late, and
  > I gather that there were changes that got lost. Or am I wrong here?
Not sure exactly what you mean.  The old ChangeLog files were purged and
thus "lost" (though we have copies and probably will make them available
separate from the main distribution).

gcc/ChangeLog.10 and gcc/ChangeLog.11 cover changes in the gcc2 tree from Nov 1995
(gcc-2.7.2 release) to the present.  gcc/ChangeLog covers the changes we've
made to egcs since we forked from the gcc2 development tree.

  > You are absolutely right. I was thinking about the snapshots, but now
  > thinking it over it is easier on the developers to carry everything around
  > and not have to add it at the end. Dismiss it as the selfish thoughts of a
  > prospective mirror ;-)
As developers, we sometimes lose sight of the so called "out of box experience".

gcc has been successful with developers because they're willing to go find
all those dependencies and pick up makeinfo, bison, gnu make, etc etc.

For egcs/gcc to take the next step forward we have to do a better job
at packaging -- it literally as to be as simple as unpack, configure, make
make install to get a fully functional toolchain.  Hell, it might even
need to be simpler than that :-)

  > OK, OK, I give up.  Must have been sleeping when I mailed you.
No problem :-)

Thanks for the feedback.
Jeff

Re: egcs-970828: Some nits

[H.J. Lu]

> 
>   In message <199709040329.XAA05067@sleipnir.valparaiso.cl>you write:
>   > Yep, the specs file is correctly installed.
> Very strange since neither Jim nor myself can figure out how/why 
> a gcc-2.7 vintage compiler could die in this manner.
> 
> It is interesting to note that his has happened only for linux folks.
> Makes me wonder if there's some braindamage going on in one of linux
> config files from gcc-2.7.
> 

What problem with Linux? I didn't see any, except for the libstdc++
one, which I have sent in patches for.

FWIW, I always use gcc 2.7.2 to bootstrap. Maybe I should use 2.7.2.3
now.

H.J.

Re: egcs-970828: Some nits

[David Bristow]

> 
> I'm thinking about adding a "bootstrap" target at the toplevel that heads
> into the gcc tree first, does a 3stage on gcc, then builds the rest of
> the tree.
> 
Please make this delete stage1 when stage2 is finished, so that you don't
have to have stage{1+2+3} worth of free disk space to do this in.

David Bristow
dbristow@lynx.dac.neu.edu

bootstrap target (was: Some nits)

[Joe Buck]

> > I'm thinking about adding a "bootstrap" target at the toplevel that heads
> > into the gcc tree first, does a 3stage on gcc, then builds the rest of
> > the tree.
> > 
> Please make this delete stage1 when stage2 is finished, so that you don't
> have to have stage{1+2+3} worth of free disk space to do this in.

Good idea.

We also need to decide where to put the instructions.  Currently the top
level README is generic, the same file used for all tools that are
packaged that way.  We could leave it and create an egcs directory with
egcs/README, plus other files with the egcs manifesto and FAQ.  But I'm
not that happy with the very generic top-level README.

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < Pine.LNX.3.95.970904211942.7585A-100000@xanadu.bogus.org >you write:
  > Please make this delete stage1 when stage2 is finished, so that you don't
  > have to have stage{1+2+3} worth of free disk space to do this in.
It's an interesting thought; though I'm not sure if it's the best thing
to do.

There's plusses and minuses for keeping and deleting the stages as
soon as possible.  Either way there'll be a group of folks that won't
be happy.

My general feeling is to leave the stage? files until they're either
removed by a make clean, or possibly after a successful 3stage + compare.

I would think the folks that need this would be in the minority, and
there _are_ ways to do this which we could document.

Jeff

Re: bootstrap target (was: Some nits)

[Jeffrey A Law]

  In message < 199709050133.SAA14017@atrus.synopsys.com >you write:
  > We also need to decide where to put the instructions.
Yes.

  > Currently the top
  > level README is generic, the same file used for all tools that are
  > packaged that way.  We could leave it and create an egcs directory with
  > egcs/README, plus other files with the egcs manifesto and FAQ.  But I'm
  > not that happy with the very generic top-level README.
Agreed.  I'd actually prefer to see the top-level README be made a little
more egcs specific _and_ point to egcs installation instructions, maybe
a faq, a pointer to the web page, etc.

Jeff

Re: egcs-970828: Some nits

[Horst von Brand]

Jeffrey A Law <law@hurl.cygnus.com> said:
[...]

> gcc has been successful with developers because they're willing to go find
> all those dependencies and pick up makeinfo, bison, gnu make, etc etc.

True. And linux from the shelf below ;-)

> For egcs/gcc to take the next step forward we have to do a better job
> at packaging -- it literally as to be as simple as unpack, configure, make
> make install to get a fully functional toolchain.  Hell, it might even
> need to be simpler than that :-)

Yes. And no. Maybe.

There _has_ to be a way of not messing up something else (texinfo is at 2.9
in egcs, I used to have 2.11 :-).

To have a toolchain-x.y.z.tar.gz of 200Mb won't go down easy on folks (egcs
is nearly 10Mb now, and that is _huge_. What if I don't want make? Or
Objective C? Or Pascal, FORTRAN, whatever?).  There will be several
separate packages, and to upgrade gui-development-x.y to x.y+1 just because
a new texinfo came out is ridiculous.  The phenomenon of
lagging-behind-packages is to be seen today, specially wrt texinfo.tex and
some elisp files, and there isn't any easy answer to that...

> Thanks for the feedback.

Just trying to give a bit back.
--
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viqa del Mar, Chile                               +56 32 672616

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < 199709050339.XAA02007@sleipnir.valparaiso.cl >you write:
  > There _has_ to be a way of not messing up something else (texinfo is at 2.9
  > in egcs, I used to have 2.11 :-).
You should find that texinfo is no longer installed as of the 970904
snapshot.  It is built for internal use during the egcs build only.

We'll be upgrading texinfo after we get the first release out the door.

  > To have a toolchain-x.y.z.tar.gz of 200Mb won't go down easy on folks (egcs
  > is nearly 10Mb now, and that is _huge_.
Yup.  That's the driving force behind breaking out the different languages and
runtimes.  That'll save folks from having to ftp, build and install languages
they don't care about (or testsuites).

The process isn't complete, but it's well under way.

Simliarly for removing old ChangeLogs from the distribution -- most folks
don't care about changes made 2+ years ago.

Once you get the languages split out, the major component of the distribution
is the config files which we'll have ot start thinking about.

Jeff