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


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: [PATCH 4/N] The big bump


* Dave Korn wrote on Sat, Aug 15, 2009 at 04:54:28PM CEST:
> Ralf Wildenhues wrote:
> > src:
> > 
> > config/ChangeLog: intl/ChangeLog: libdecnumber/ChangeLog: etc/ChangeLog: 
> > sim/common/ChangeLog: sim/iq2000/ChangeLog: sim/d10v/ChangeLog: 
> > sim/igen/ChangeLog: sim/m32r/ChangeLog: sim/frv/ChangeLog: sim/ChangeLog: 
> > sim/h8300/ChangeLog: sim/mn10300/ChangeLog: sim/ppc/ChangeLog: 
> > sim/erc32/ChangeLog: sim/arm/ChangeLog: sim/m68hc11/ChangeLog: 
> > sim/lm32/ChangeLog: sim/sh64/ChangeLog: sim/v850/ChangeLog: 
> > sim/cr16/ChangeLog: sim/moxie/ChangeLog: sim/m32c/ChangeLog: 
> > sim/mips/ChangeLog: sim/mcore/ChangeLog: sim/testsuite/d10v-elf/ChangeLog: 
> > sim/testsuite/ChangeLog: sim/testsuite/frv-elf/ChangeLog: 
> > sim/testsuite/m32r-elf/ChangeLog: sim/testsuite/mips64el-elf/ChangeLog: 
> > sim/sh/ChangeLog: gold/ChangeLog: gprof/ChangeLog: libiberty/ChangeLog: 
> > ChangeLog: opcodes/ChangeLog: readline/examples/rlfe/ChangeLog: 
> > gas/ChangeLog: ld/ChangeLog: gdb/ChangeLog: gdb/doc/ChangeLog: 
> > gdb/gdbserver/ChangeLog: gdb/testsuite/ChangeLog: binutils/ChangeLog: 
> > bfd/ChangeLog: bfd/doc/ChangeLog: readline/ChangeLog.gdb:
> 
>   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/.

That is correct.

>  Are these all unaffected or are some of them liable to need updates too?

I have never ever gotten a full src tree to cleanly build with
--enable-maintainer-mode, and IIRC not even without.  I've always just
worked on the git binutils-gdb mirror.  The rest of the tree has IMHO
lacked lots of love at least on the build system side.  If you tell me
that it is used actively, and they are generally willing to see updated
build machinery (and there is somebody to review patches to this end,
timely, too), then I would look into this task.  But last time I looked
I didn't think a drift apart would make things any worse; for example,
Autoconf versions used were quite inconsistent already.

Sorry if I've misunderstood things there.

I hope there is a chance this does not need to happen in lock step.

Cheers,
Ralf


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