Re: [PATCH 4/N] The big bump

Re: [PATCH 4/N] The big bump

[Ralf Wildenhues]

* 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

Re: [PATCH 4/N] The big bump

[Paolo Bonzini]

On 08/18/2009 09:14 PM, Ralf Wildenhues wrote:
>    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?

As far as I'm concerned, yes.  Nothing outside binutils/gdb/gcc has ever 
cared much about Autotools versions (and some parts like newlib/libgloss 
and winsup are not even CCed), it should be fine as long as we provide 
override.m4 to cover their bugs.

Paolo

Re: [PATCH 4/N] The big bump

[Tom Tromey]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

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

I don't think there is one; AFAIK there are only git trees for a couple
parts of src.

Ralf> - parts of itcl with 2.61,
Ralf> - parts of tk and parts of tcl with 2.60a,

My understanding is that gdb changes can be made without worrying about
the consequence to the Insight bits, because Insight is not "official"
in some way.

I would suggest that this also applies to build infrastructure -- IMO it
would be ok for you to move forward with the main parts and fix this up
later.

Ralf> This patch series is almost ready to go otherwise (expect to be able to
Ralf> commit this weekend), and it'd be sad to see it hostage of the lesser
Ralf> tightly maintained part of the tree.

FWIW, I tend to agree.  I know this sort of change is very difficult to
get in and I think it would be worthwhile to bend the rules a little to
make it simpler for you.

Tom

Re: [PATCH 4/N] The big bump

[Dave Korn]

Ralf Wildenhues wrote:

> Oberving build times: Cygwin takes several hours to build.

  That can't be right.  What did you do, and what hardware are you using?

    cheers,
      DaveK

Re: [PATCH 4/N] The big bump

[Christopher Faylor]

On Tue, Aug 18, 2009 at 01:57:19PM -0600, Tom Tromey wrote:
>>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>Ralf> Thanks guys.  Does anyone have an up to date git clone of the full src
>Ralf> tree?  If not, are there any volunteers to set one up, or can I bribe
>Ralf> one?
>
>I don't think there is one; AFAIK there are only git trees for a couple
>parts of src.
>
>Ralf> - parts of itcl with 2.61,
>Ralf> - parts of tk and parts of tcl with 2.60a,
>
>My understanding is that gdb changes can be made without worrying about
>the consequence to the Insight bits, because Insight is not "official"
>in some way.
>
>I would suggest that this also applies to build infrastructure -- IMO it
>would be ok for you to move forward with the main parts and fix this up
>later.
>
>Ralf> This patch series is almost ready to go otherwise (expect to be able to
>Ralf> commit this weekend), and it'd be sad to see it hostage of the lesser
>Ralf> tightly maintained part of the tree.
>
>FWIW, I tend to agree.  I know this sort of change is very difficult to
>get in and I think it would be worthwhile to bend the rules a little to
>make it simpler for you.

I mainly agree but I'd like to know exactly what the "lesser tightly
maintained part" means since that is a judgement call rather than an
objective determination.

cgf