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

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

On Mon, 10 Jun 2024 13:27:51 -0600,
Joseph Myers wrote:
> On Fri, 7 Jun 2024, Luke T. Shumaker wrote:
> 
> > 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.
> 
> That process still seems excessively complicated.
> 
> Preferred process:
> 
> * Precondition: the shared files and directories are in sync.
> 
> 1. A patch is committed to both places.
> 
> * Postcondition: the shared files and directories are still in sync.

The problem with that is that the precondition is--at this moment--not met.
Which is to say: Past attempts at this process have failed to fulfill
the postcondition.

> You seem to be suggesting a more complicated process involving committing 
> to one place, also committing a .patch file there, committing to the other 
> place, then doing a second commit to the first place to remove the .patch 
> file and update a commit hash.

Mostly; but the last commit could be "lazy", the .patch files can
stick around until the next time there's something to sync in the
other direction.

I'll admit, It's not a great process.  But we've seen patches get
lost-track-of, and never get synced to gcc.  The process isn't
*terrible*, and should make it so that things don't get lost track of
and the postcondition isn't violated for as long.

Anyway, my goal with this patchset isn't yet to induce any process
change, it's to document how things are right now.

>                                                                (Files such 
> as Makefile.def are definitely included in this, not just shared 
> subdirectories.)

Oh shoot, I didn't realize that Makepkg.def is shared.  I'll adjust
the patchset in v3 to include it.

-- 
Happy hacking,
~ Luke T. Shumaker