Re: [patch, libtool] Patch libtool.m4 at top-level for autoconf 2.68

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 23 Aug 2013, Tom Tromey wrote:

> Joseph> There is no automatic merging at toplevel, only for certain
> Joseph> subdirectories (because of a lack of consensus on making GCC the
> Joseph> master for all the shared toplevel files).
> 
> How about we reopen this and try to get consensus?
> 
> I don't remember the last time this came up.  So I don't know what the
> arguments are.  However it seems to me that gcc-as-master has worked out
> reasonably well for libiberty and other files -- what makes top-level
> different?

I suspect noone ever seriously tried to get consensus.

I suggest defining a new ChangeLog.toplevel file that will be used to get 
ChangeLog entries for shared toplevel files in future, to avoid issues 
with that.

(Apart from ChangeLog, MAINTAINERS and README exist in both trees and are 
deliberately different.  I don't know if it's deliberate that COPYING.LIB 
has an older version in the src tree.  include/ in GCC is a subset of what 
it is in src, with consequent ChangeLog implications.  My inclination is 
that include/ should be split up, so the shared bits end up in 
libiberty/include and the unshared bits in binutils/include or bfd/include 
or similar, but that would require working out whether anything in 
include/ is in fact used by some other bit of the tree in a way that 
wouldn't work with those moves[*].  Certainly if it could be made so that 
all shared files/directories are identical in all repositories using them, 
that would simplify merges, especially when three or more repositories end 
up being involved.)

[*] utils/ and rda/ and sid/ appear to use include/ but I haven't 
investigated whether they use anything more than the shared subset if 
that.  If the non-shared parts did move to binutils/include, it would be 
inappropriate for them to be used by anything not ending up in the 
binutils+gdb repository.

-- 
Joseph S. Myers
joseph@codesourcery.com