Hello, I have a custom protocol that contains a variable of type `Short` within a struct which I have now realised would be better off using a `Long`.\ I have used this protocol in a lot of custom components and workers and so it would be frustrating if I have to manually recreate workers for each component that uses it in order to have the workers’ header files match the XML. Is there a command I can run that will automatically update the workers to match the updated XML\ Alternatively can I just change the underlying data type from `int16_t` to `int32_t` in the Properties struct of each header file? Many thanks,\ Dan

You should be able to issue a 'ocpidev clean' from the component library or worker directory then rebuild them using `ocpidev build` the act of rebuilding will update the header file with the correct value based on the OpenCPI component specification (OCS). Aaron On Tue, May 16, 2023 at 9:24 AM <dwp@md1tech.co.uk> wrote: > Hello, > > I have a custom protocol that contains a variable of type Short within a > struct which I have now realised would be better off using a Long. > I have used this protocol in a lot of custom components and workers and so > it would be frustrating if I have to manually recreate workers for each > component that uses it in order to have the workers’ header files match the > XML. > > Is there a command I can run that will automatically update the workers to > match the updated XML > Alternatively can I just change the underlying data type from int16_t to > int32_t in the Properties struct of each header file? > > Many thanks, > Dan > _______________________________________________ > discuss mailing list -- discuss@lists.opencpi.org > To unsubscribe send an email to discuss-leave@lists.opencpi.org >

Thanks! This worked

In general, you should never have to edit files that OpenCPI generates in `gen` or `target-*` directories. If you feel like you need to: `ocpidev clean` then `ocpidev build`. On Wed, May 17, 2023 at 9:07 AM <dwp@md1tech.co.uk> wrote: > Thanks! This worked > _______________________________________________ > discuss mailing list -- discuss@lists.opencpi.org > To unsubscribe send an email to discuss-leave@lists.opencpi.org >

 Thanks! This worked

 _______________________________________________
 discuss mailing list -- discuss@lists.opencpi.org
 To unsubscribe send an email to discuss-leave@lists.opencpi.org

In fact, if "ocpidev build" by itself does not solve the problem, it means there could be a dependency bug in "ocpidev build". I.e. the "clean" action is only needed to overcome a change that "ocpidev build" somehow does not recognize based on file modification dates. Unless modification dates have been hacked somehow, any change should be automatically recognized and cause a rebuild. An example of a change that "ocpidev build" would *not* recognize is when some input file was replaced with a different one that was still older than the last build. Some build systems actually look at hashes of input files rather than modification dates, but OpenCPI doesn't. Thus "clean" is indeed needed when something unusual like this happens. On 5/17/23 2:35 PM, Dominic Walters via discuss wrote: > In general, you should never have to edit files that OpenCPI generates > in `gen` or `target-*` directories. > If you feel like you need to: `ocpidev clean` then `ocpidev build`. > > On Wed, May 17, 2023 at 9:07 AM <dwp@md1tech.co.uk> wrote: > > Thanks! This worked > > _______________________________________________ > discuss mailing list -- discuss@lists.opencpi.org > To unsubscribe send an email to discuss-leave@lists.opencpi.org > > > _______________________________________________ > discuss mailing list --discuss@lists.opencpi.org > To unsubscribe send an email todiscuss-leave@lists.opencpi.org