On Wed, Feb 14, 2024 at 1:37 PM Kinsey Moore <kinsey.mo...@oarcorp.com> wrote:
> On Wed, Feb 14, 2024 at 9:14 AM Sam Price <thesampr...@gmail.com> wrote: > >> I was wondering if you had any notes on your process of working with >> qemu in the rtems builder. >> I imagine you have your own xilinx qemu forked to work on, and then >> take the patches and integrate them into the rsb builder? >> > > Nothing so fancy. Here's my current setup for this: > * have a checkout of the qemu-xilinx repo to generate patches > * copy generated patches into the rsb/rtems/patches directory > * set up the RSB recipe to pull in the patch with appropriate SHA512 > * attempt build > > This lets me pull in a custom patch for testing without actually hosting > it somewhere. I've been wanting an easier way to do this since it's a pain > to push patches elsewhere for test hosting before actually pushing it to > the ticket, but this is the compromise I've settled on that smooths out the > workflow just enough. Ideally, I'd be able to specify a local file path for > a patch for test purposes, but that would necessitate some very verbose > flag to sb-set-builder like > --really-allow-local-patches-just-for-test-purposes because we really don't > want to host these patches within RSB. > This is essentially what I have done when generating patches for newlib, gcc, etc. For some packages, you need a patch based on git and sometimes you have to generate one against a released version. But you still have to put a patch in your patches directory and update the sha hash. Eventually putting the working patch somewhere (hopefully merged upstream) not local. --joel > > Kinsey > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
