Details
Description
Random thoughts:
- The target artifact(s) should (by default) be listed in the generated module. Users must be able to opt out (e.g. via a file tag filter). There should be reasonable defaults for well-known product types (e.g. do not export dynamiclibrary_symbols, but do export dynamiclibrary_import).
- Most properties set in an Export item should be pulled into the module with the literal value, but some of them should not: In particular, expressions in top-level properties which refer to "product" (i.e. the exporting product) need to be evaluated. It may or may not be necessary to make that configurable per property. Simple approach: If users want their value to go into the module evaluated, then they need to make it a product property and refer to it via the product variable in the Export item. Good enough?
- The user needs to be able to opt out of certain properties and/or dependencies (example: internal modules that are only needed for the properties to appear on the right-hand side of expressions). It remains to be seen how flexible we want to make this: E.g. should the user be able to see and transform the entire AST?
- Imports: We can scan for the use of built-in services such as qbs.TextFile, and add the respective imports to the generated module automatically. What about user-provided JS imports? Should we try to be super-smart and auto-deploy them, or even unfold the functions in them? It probably suffices to let the user be responsible for that, at least for the first implementation.