GSOC: Adding all generated changes in patch to RSB?

[Matthew Joyce]

Dr. Joel,

Thanks! This made me re-read your discord workflow advice from last
week, and it brings me to another question...You wrote:

"You don't have to rebuild the entire toolsuite at this point. Just
add a functional test for sig2str.c to the testsuite (e.g. psxsigNN or
similar based on existing names). You have your implementation in your
local newlib patches."

I did add the test, but I don't quite understand "you have your
implementation in your local newlib patches." Do you mean the
sig2str.c patch plus generated files? Where exactly is it supposed to
be? Am I following the instructions Vaibhav lays out minus the toolset
rebuilding? (patch in rtems/rsb/patches, calculate sha512, edit .cfg
used by .bset file?)

Once it's set, If I'm not rebuilding the toolset, I'd guess I go
straight to steps 2.5, 2.6 in the quick-start guide?

Thank you again for your help!

Sincerely,

Matt

On Tue, Jun 29, 2021 at 3:45 PM Joel Sherrill <joel at rtems.org> wrote:
>
> On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce <mfjoyce2004 at gmail.com> wrote:
> >
> > Dear Mentors,
> >
> > I've implemented my new functions locally in Newlib, created basic
> > tests in RTEMS, now I want to add the patches to the RSB to test them.
> >
> > I think I understand that once I submit these patches to newlib, they
> > should only include the added lines of source code...not any changes
> > generated through the build process.
>
> +1
>
> > However, when I make a patch to add to RSB and test, I need to include
> > everything, right? There are probably about 100 modified files from
> > the reconf / build. Should I:
> > 1) "git add --all" to add the whole load of new files and changes
> > 2) make the commit
> > 3) git format patch
>
> Yes -- the RSB patch must include the generated files. But this patch set
> and RSB modifications are only for your use. Before RTEMS.org RSB is
> updated, the patch must be in the upstream newlib and we will just bump
> the newlib hash. That's why I suggested just building newlib (j-newlib, make,
> make install, etc) locally without the RSB and testing that way.
>
> With that said, there are a couple of things to do here:
>
> + Do NOT put generated files in your main patch. Make them a separate
> patch in the set so they are easy to ignore.
>
> + Reverse the generated changes to anything that shouldn't change based
> on what you touched. These are just due to autoconf version difference. In your
> case, I think this means you only need signal/Makefile.in. The rest are
> unneeded.
>
> + Only submit the patches with manual changes for review. Submit to devel@
> and when it passes review, it goes to newlib.
>
> When the work is merged into newlib, you can update the RSB newlib hash
> and submit your tests to RTEMS. You will have to track the status of
> outstanding work and continue on to the next thing while the review process
> moves along.
>
> FWIW Eshan ended up tracking patches for a few months after last year's
> GSoC ended before we cleared his queue up.
>
> --joel
>
> >
> > Just want to make sure I'm understanding this point...
> >
> > Thank you!
> >
> > Sincerely,
> >
> > Matt