Dear Philip, Another thing to pay attention to is the move to Sphinx for documentation: https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html
Best, Manuel. On Wed, 10 Aug 2022 at 20:57, Philip Herron <philip.her...@embecosm.com> 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? In theory, > when everything goes well, does this still mean that we can merge in > one commit, 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 > > > >
