This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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