Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update build and plugin packages to support JS code generation #479

Closed
chrispcampbell opened this issue May 5, 2024 · 1 comment · Fixed by #487 or #476
Closed

Update build and plugin packages to support JS code generation #479

chrispcampbell opened this issue May 5, 2024 · 1 comment · Fixed by #487 or #476

Comments

@chrispcampbell
Copy link
Contributor

chrispcampbell commented May 5, 2024

After we add the initial support for JS code generation in the cli, compile, and runtime packages (see #437), we need to update the following packages to allow for choosing between C and JS code generation:

  • build
  • plugin-wasm
  • plugin-worker

In the UserConfig interface (and sde.config.js file), I will add a switch to control which code format to generate:

  /**
   * The code format to generate.  If 'js', the model will be compiled to a JavaScript
   * file.  If 'c', the model will be compiled to a C file (in which case an additional
   * plugin will be needed to convert the C code to a WebAssembly module).  If undefined,
   * defaults to 'js'.
   */
  genFormat?: 'js' | 'c'

In the Plugin interface, I'm planning to remove pre/postGenerateC and replace them with:

  preGenerateCode(context: BuildContext, format: 'js' | 'c'): string
  postGenerateCode(context: BuildContext, format: 'js' | 'c', content: string): string

Currently plugin-worker assumes that plugin-wasm is used, and has code that is specific to the wasm case (like initializing a WasmModel that includes the outputVarIds). I plan to change this so that plugin-wasm injects the outputVarIds into the generated module. That way, plugin-worker can be simplified to load either a Wasm model or a JS model.

@chrispcampbell
Copy link
Contributor Author

Here's a summary of the changes that were included in this branch. Most of these changes will have no impact on users, except for the first one flagged below with the ⚠️ icon.

API changes in the @sdeverywhere/build package

  • ⚠️ Added genFormat property to UserConfig; if not specified in the user's sde-config.js, it will default to 'js'. NOTE: Previously the default was effectively 'c', so any projects that use plugin-wasm will need to be updated to set genFormat: 'c'.
  • Removed preGenerateC and postGenerateC in the Plugin interface; these have been replaced with preGenerateCode and postGenerateCode that work with either JS or C code generation.

Behavior changes in the build and plugin packages

  • Prior to these changes, for any project that uses sde bundle or sde dev with a sde-config.js file, the builder would generate C code only, and plugin-wasm was required to generate a working model. The new default behavior (if genFormat is not specified in the sde-config.js file) is to generate JS code, so any projects that use plugin-wasm will need to be updated to set genFormat: 'c'.
  • Prior to these changes, plugin-wasm would generate a file called wasm-model.js under the configured prepDir (typically this is the sde-prep directory). With these changes, when genFormat is unspecified or set to 'js'), the builder will generate a JavaScript model to a generated-model.js file. Or, if you set genFormat: 'c' and use plugin-wasm, the plugin will generate a file called generated-model.js containing the Wasm model. Since the file name and location are the same, and both can be initialized the same way, this simplifies the initialization process.
  • Fixed the plugin-{check,config,wasm} packages to use comma as separator when generating canonical IDs. This matches the behavior of the similar code in the compile package. (This should have no impact on most users.)

Other minor user-facing changes

  • Removed plugin-wasm from the hello-world example; it now generates JavaScript code only so that extra software is not required to run it.
  • Changed the @sdeverywhere/create flow to default to JS target; it now only asks to install the Emscripten SDK if the user chooses to use WebAssembly.
  • Changed template-default and template-minimal (used by the @sdeverywhere/create package) to work regardless of whether the user chooses to target JS or C/WebAssembly.
  • Updated the @sdeverywhere/create package so that it requires Node.js v18 or later. (The rest of SDEverywhere was updated a while ago to use Node.js v18 at minimum, but this case was overlooked at the time, so it has now been corrected.)

Other internal changes

  • Updated the JS-level integration tests so that they target the JS code gen case in addition to the existing C/Wasm case. This means that for each test model under the tests/integration directory, we now run the test 4 ways: JS/synchronous, JS/asynchronous, Wasm/synchronous, Wasm/asynchronous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment