This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crosstool-0.40 released: gcc-4.1 rc1 support


On Tue, 21 Feb 2006, Robert Schwebel wrote:

> - I'm not sure what is your intention of supporting _all_ gcc/glibc/...
>   versions out there, and I doubt that this is maintainable. There are
>   the gcc major versions:
>
> 	2.95
> 	3.3
> 	3.4
> 	4.0
> 	4.1
> 	4.2
>
>   Always combinded with the latest glibc (2.3.6). IMHO a toolchain build
>   script shouldn't encourage people to use stuff from the past - the
>   patch mess is clearly visible. When things for 3.3.1 have been fixed
>   in 3.3.6, why still provide 3.3.1? If somebody needs it, he can use
>   an old crosstool which supports it.

  hmmmm ... i vaguely recall someone making a suggestion like this not
long ago.  hey, wait ... that was *me*. :-)

  in any event, it would seem that the first step in getting rid of
cruft would be to remove support for all obsolete, dated CVS
checkouts.  for example, the patches/ directory contains the following
subdirectories for various versions of glibc:

glibc-20040822
glibc-20040827
glibc-20050502
glibc-2.1.3
glibc-2.2.2
glibc-2.2.3
glibc-2.2.5
glibc-2.3.2
glibc-2.3-20050307
glibc-2.3.3
glibc-2.3.4
glibc-2.3.5
glibc-2.3.6

  at the very least, it would seem to be a no-brainer to remove all of
those dated versions of glibc.  even if you can make a case for
retaining numbered *official* versions, i'm not sure there's any point
in having a patches directory for, say, glibc-20040822.  more
generally, is there any problem with having a policy that *all* dated
CVS checkouts will be removed once the next official numbered version
is released?  (unless there's some really exceptional circumstances.)

  and, following robert's train of thought, at what point can even
*numbered* versions be removed (or at least no longer officially
supported)?  granted, i don't have the historical knowledge to know if
this is reasonable but, once you have, say, binutils-2.16.1, is there
a whole lot of value to binutils-2.11.2?

  (aside:  i can appreciate the inevitable argument that having old
software directories doesn't really *hurt* anything but it might be
better to look at it this way:  if a certain version of software has a
patch directory in crosstool, that implicitly says that it's
supported and users have the right to expect help with it.  if it's so
old that no one really wants to support it any more, it should be
removed.)

  and following up on the above, stuff that is obsoleted from the
patches/ directory should also have all references to it deleted from
the various .dat files, no?  as a simple example, look at the contents
of the demo file "demo-i386.sh":

#eval `cat i386.dat gcc-2.95.3-glibc-2.1.3.dat` sh all.sh --notest
#eval `cat i386.dat gcc-2.95.3-glibc-2.2.2.dat` sh all.sh --notest
#eval `cat i386.dat gcc-3.2.3-glibc-2.2.5.dat`  sh all.sh --notest

<BIG snip here>

#eval `cat i386.dat gcc-4.0-20050305-glibc-2.3.4.dat` sh all.sh --notest
#eval `cat i386.dat gcc-4.0-20050305-glibc-2.3-20050307.dat` sh all.sh --notest


  perhaps it would be useful to minimize the contents of the demo
files, if only for aesthetic reasons.  at the very least, there should
be no entries that refer to unsupported versions of software anymore.

rday

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]