On Wed, 2022-08-10 at 19:56 +0100, Philip Herron wrote: > Hi everyone > > For my v2 of the patches, I've been spending a lot of time ensuring > each patch is buildable. It would end up being simpler if it was > possible if each patch did not have to be like this so I could split > up the front-end in more patches. Does this make sense?
Yes. I've often split up patches into chunks when posting them for review, and I see other people here do that. It makes it easier for the reviewer also, since it's usually easier to deal with e.g. 10 small patches than one enormous one (e.g. if many of them are uncontroversial, having them split up makes it easier to focus attention on just the controversial areas). > In theory, > when everything goes well, does this still mean that we can merge in > one commit, Split up the patches for review, but make a note in the cover letter than they would all be merged into one when committing. (especially if doing the split is taking up a lot of time; we don't want to be mandating busy-work) Dave > or should it follow a series of buildable patches? I've > received feedback that it might be possible to ignore making each > patch an independent chunk and just focus on splitting it up as small > as possible even if they don't build. > > I hope this makes sense. > > Thanks > > --Phil > > On Thu, 28 Jul 2022 at 10:39, Philip Herron < > philip.her...@embecosm.com> wrote: > > > > Thanks, for confirming David. I think it was too big in the end. I > > was > > trying to figure out how to actually split that up but it seems > > reasonable that I can split up the front-end patches into patches > > for > > each separate pass in the compiler seems like a reasonable approach > > for now. > > > > --Phil > > > > On Wed, 27 Jul 2022 at 17:45, David Malcolm <dmalc...@redhat.com> > > wrote: > > > > > > On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc- > > > patches > > > wrote: > > > > This is the initial version 1 patch set for the Rust front-end. > > > > There > > > > are more changes that need to be extracted out for all the > > > > target > > > > hooks we have implemented. The goal is to see if we are > > > > implementing > > > > the target hooks information for x86 and arm. We have more > > > > patches > > > > for the other targets I can add in here but they all follow the > > > > pattern established here. > > > > > > > > Each patch is buildable on its own and rebased ontop of > > > > 718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we > > > > keep > > > > attribution for all the patches we have received in the front- > > > > end > > > > should we create a CONTRIBUTOR's file inside the front-end > > > > folder? > > > > > > > > Note thanks to Thomas Schwinge and Mark Wielaard, we are > > > > keeping a > > > > branch up to date with our code on: > > > > > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master > > > > but this is not rebased ontop of gcc head. > > > > > > > > Let me know if I have sent these patches correctly or not, this > > > > is a > > > > learning experience with git send-email. > > > > > > > > [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end > > > > folder > > > > [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for > > > > i386 and > > > > [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM > > > > [PATCH Rust front-end v1 4/4] Add Rust front-end and associated > > > > > > FWIW it looks like patch 4 of the kit didn't make it (I didn't > > > get a > > > copy and I don't see it in the archives). > > > > > > Maybe it exceeded a size limit? If so, maybe try splitting it up > > > into > > > more patches. > > > > > > Dave > > > >
