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 <j...@rtems.org> wrote: > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce <mfjoyce2...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel