> 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 <j...@rtems.org> wrote: > > On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce <mfjoyce2...@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 <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
