search

locka99 / opcua

A client and server implementation of the OPC UA specification written in Rust
Mozilla Public License 2.0
480 stars 129 forks source link

Fix module paths for BSD module generator #155

Open Pascal-So opened 2 years ago

Pascal-So commented 2 years ago

In pull request #154 the core functionality from the existing gen_types.js was extracted into the separate types.js file so that gen_datatypes.js can also use it to generate types for other BSD files besides Opc.Ua.Types.bsd.xml. Unfortunately the use paths in the generated rust code still assumed that the generated code would be placed in the opcua-types crate.

This pull request changes this so that the generated module can be used without having to adjust anything at all ideally (except for maybe sometimes changing CharArray to UAString or something like that). I also added some more documentation in tools/schema/README.md.

locka99 commented 2 years ago

Check the changes I've made recently to clean up the code. Is it necessary for a codegen_info struct with that in mind?

Pascal-So commented 2 years ago

Thanks for working on this! I agree that the codegen_info struct is not really necessary for the comment handling.

However I'm not sure how we can handle the different imports required for the two uses of types.js. When called from gen_types.js, the generated files are placed in a directory together with the handwritten impls.rs. But when generating code for a third-party BSD file using gen_datatypes.rs we don't place the code in the same location but rather into a crate created by the user of this library. Therefore we either have to change the path to impls or skip it if it's not needed. A similar issue can be observed for use crate::encoding::*; and use crate::status_codes::StatusCode; which of course doesn't work from outside the opcua-types crate.

Note that this is very low priority because pragmatic users can solve it right now by simply manually fixing a few paths once for their generated code. I'm just thinking that maybe at some point in the future we could even have a workflow where users of the library generate their nodesets and datatypes in a build.rs script "à la bindgen", and only have to commit the XML/BSD files instead of the generated code.

If you want I could re-open issue #153 where we could organize the discussion more visibly. Alternatively I can also completely understand if this use case is not a priority for you. I highly appreciate the work you are putting into this library, so I don't want to eat up too much of your time with low-priority issues. My original use case has in the meantime been solved by using the code in this PR, but I'd anyway be open to collaborate on this.

antiblue commented 1 year ago

Hi all, what is the status of this?

evanjs commented 8 months ago

... I'm just thinking that maybe at some point in the future we could even have a workflow where users of the library generate their nodesets and datatypes in a build.rs script "à la bindgen", and only have to commit the XML/BSD files instead of the generated code.

I actually have reached this point with a build.rs script. I have it down to just a few lines that need to be specified for each new spec to be generated.

The problem I am facing now is that "a few paths needing to be changed" is much more tedious when the modules are generated via build.rs

Is this task still low priority?

locka99 commented 6 months ago

Yes it's low priority. There are tools to generate nodesets from a schema that you can manually invoke and compile. I suppose it could be put into a build script but then it would involve running NodeJS from Rust to create a file which rarely changes after it is generated.