Re: [PATCH 4/4] Add a ./bootstrap script to automate bundling and generating files

[Luke T. Shumaker <lukeshu@lukeshu.com>]

On Thu, 06 Jun 2024 14:57:26 -0600,
Joseph Myers wrote:
> 
> On Thu, 6 Jun 2024, Luke T. Shumaker wrote:
> 
> >    * config/patches/
> >    * libdecnumber/patches/
> >    * libiberty/patches/
> 
> In my view, rather than maintaining binutils-local patches to these 
> directories, we should treat GCC and binutils as equally canonical for 
> them; any change approved and applied in one tree but not the other should 
> be treated as thereby approved for the other tree as well, and get 
> committed there (post to the relevant patches list and commit, without 
> seeking separate approval).  That way, the only differences between the 
> two trees should be in the ChangeLog files (reflecting when changes were 
> applied to the two trees).

Binutils' libdecnumber is more than 6 years behind GCC's (last synced
from GCC on 2018-02-19).  Carefully identifying how they have diverged
is, IMO, the first step in re-unifying the two.  (That said,
libdecnumber is fairly inactive so it's not too bad, and the other
directories are much more up-too-date.)

Like, I anticipate that in the near future I will be `git
send-email`ing most of the .patch files being added to the various
other repos (well, maybe not verbatim `git send-email`, I anticipate
merge conflicts).

Even after the two are in better sync, I think that having 'patches/'
as a live a record of "changes that still need to be copied over" is
probably a pretty good workflow; in many cases they can even be
applied with `git am` and sent with `git send-email`.  So, for
example: whatever.patch is approved to binutils; and is commited to
binutils.git/libiberty/patches/whatever.patch.  That patch is then
applied to GCC.  The next time someone bumps the commit hash in
binutils.git/bootstrap.d/bundle-gcc.mk ty sync with GCC, `patch` will
complain that the patch has already been applied, and then the person
can delete the patch file.

> The same applies to files at top-level present in both trees, except for 
> ChangeLogs, README, MAINTAINERS and SECURITY.txt which are genuinely meant 
> to be different: any difference between other top-level files in the two 
> trees is a bug that should be reconciled by ensuring all patches have been 
> applied to both places.  Also to files (other than ChangeLogs) in include/ 
> that are present in both trees (but some files in include/ are 
> legitimately present only in one of the two trees).
> 
> Effectively, rather than treating GCC as the upstream for any files, treat 
> it as indicating a bug if GCC and binutils-gdb differ for various files - 
> including toplevel ones that actually come from other sources such as 
> libtool - but with neither tree as upstream of the other.

So interpret each old `bundle-gcc.mk:downloads/git/gcc.commits/*`
commit hash and `*.patch` file as a "BUG"/"TODO"/"FIXME" comment.

> (Special-case exception: if one of binutils-gdb and GCC has updated 
> autoconf/automake/libtool and the other one hasn't updated yet, there may 
> temporarily be differences in such files - though if a change to work with 
> newer versions of autoconf/automake doesn't break older versions, it 
> should be applied to both trees.  This exception is because such updates 
> can be complicated, so are more likely to happen if only one tree needs 
> updating at a time.)

-- 
Happy hacking,
~ Luke T. Shumaker