Re: GSOC: Adding all generated changes in patch to RSB?
> 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 wrote: > > On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce 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 wrote: > > > > > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce > > > 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
Re: GSOC: Adding all generated changes in patch to RSB?
On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce 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 wrote: > > > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce 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
Re: GSOC: Adding all generated changes in patch to RSB?
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 wrote: > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce 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
Re: GSOC: Adding all generated changes in patch to RSB?
On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce 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
GSOC: Adding all generated changes in patch to RSB?
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. 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 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
