GSOC: Adding all generated changes in patch to RSB?

[Matthew Joyce]

> 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?

I'm sorry, I should have been more specific...I meant 2.5 (Build a
BSP) and 2.6 (Test a BSP) from the RTEMS quick-start?

Thanks again!

On Tue, Jun 29, 2021 at 7:21 PM Joel Sherrill <joel at rtems.org> wrote:
>
> On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce <mfjoyce2004 at gmail.com> wrote:
> >
> > 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?
>
> Yes. Your changes to newlib are captured in 1+ changes to hand-written
> source files and 1 patch to hold the generated files that really needed to
> change.
>
> > 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?)
> >
>
> Yes. You only modified newlib and that's all that needs rebuilding
> until the RSB hashes change. You do not need to build binutils, gcc,
> gdb, and the other libraries every time.
>
> Plus using the RSB method, you are rebuilding newlib from scratch
> every time.
>
> Sometimes you will need to do a clean build but for the most part
> while editing a file in newlib that has been added to the Makefile.am,
> stuff regenerated, and a clean first "j-newlib" build with that, you can
> just do make/make install.
>
> > 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?
>
> I don't know his step numbers but probably.
>
> The key is to be aware of when you need to build newlib from
> scratch and when you need to address the RSB.
>
> --joel
>
> > 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