Re: [PATCH 4/N] The big bump

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

* Joseph S. Myers wrote on Sat, Aug 15, 2009 at 06:26:38PM CEST:
> On Sat, 15 Aug 2009, Dave Korn wrote:
> 
> >   Looking at the toplevel of/src, there are no changes to blt/, cgen/, cpu/,
> > dejagnu/, elfcpp/, expat/, expect/, itcl/, iwidgets/, libgloss/, libgui/,
> > mmalloc/, newlib/, rda/, sid/, tcl/, texinfo/, tix/, tk/, utils/ and winsup/.
> >  Are these all unaffected or are some of them liable to need updates too?
> 
> Some of these do not exist on HEAD; they only have files in the Attic.  
[...]
> I think cgen/ libgloss/ libgui/ newlib/ rda/ sid/ utils/ winsup/ actually 
> live in the src repository as their main home.

Plus sim/, as Tom noted.

* Dave Korn wrote on Sat, Aug 15, 2009 at 06:49:39PM CEST:
> 
>   Well, the winsup/ directory is pretty heavily used, winsup == cygwin +
> mingw!  I can help with the testing if you can help with the patching; winsup
> depends on newlib, so I can test those together for you.  I think Joseph's
> cut-down list looks about right for the rest.

Thanks guys.  Does anyone have an up to date git clone of the full src
tree?  If not, are there any volunteers to set one up, or can I bribe
one?

I have ventured a wee bit into building the whole tree, GNU/Linux and
Cygwin native builds.

Observing the autotools version used right now:

- sid/component/tcl was configured with Autoconf 2.61,
- parts of winsup with Autoconf 2.63,
- parts of itcl with 2.61,
- parts of libgloss with 2.61,
- parts of tk and parts of tcl with 2.60a,

Automake 1.9.3 has seen usage, 1.9.5 and 1.10 (sid), 1.4 and 1.4-p5
(rda, libgloss, utils are all candidates).

- libgloss/testsuite and ../libgloss.all has files named configure.in
  which are not meant to be input files to autoconf (and are probably
  dead for 12 years?).

Oberving build times: Cygwin takes several hours to build.

A conservative estimate is that I will need around 10 or more builds to
get the current tree to run without and with maintainer-mode enabled,
then update autotools, then retry the same again, plus bugfixing on the
way, then sort patches in logical order and retry patches in that order.
(This is how I did the rest of the tree, during the last months; if you
like, I can post a detailed recipe).

So, I expect this to take a few weekends, even without more surprises.
In light of the expected Stage 1 end for GCC, allow me to ask again:

  May I proceed in updating the tree to 2.64/1.11 before getting the rest
  of the tree (that already has out-of-sync autotools) back into sync?

This patch series is almost ready to go otherwise (expect to be able to
commit this weekend), and it'd be sad to see it hostage of the lesser
tightly maintained part of the tree.  (Not to speak of the extra work
required to keep the current patch series in sync with other changes
while it is still pending.)

Thanks,
Ralf