There's some interesting notes on the IDE's 'package' format used with extension in the source C++ comments:
https://github.com/OpenXTalk-org/OpenXT ... C1-L157C86
I'll add my own emphasis and responses here in an attempt to correct some no-longer accurate or updated things:
// Packages are a collection of modules which share a common set of foreign
// code and resources.
Just to be clear here, package modules don't necessarily use any foreign code or other resources.
Library modules don't even need to be written using XTension Buider, they can be written in regular XT script so long as they have the extension initialization/uninitialize handlers (a few examples script-libraries-as-extensions already come with the IDE)
// When a package is loaded into memory, all its modules are loaded also making
// them available in the module namespace and accessible through the module functions.
I remember reading somewhere that you could have main-module and sub-modules but I've still never seen a package that did this
// A package loaded from a particular file, or with a particular name can only
// be loaded once - if an attempt is made to load a package from a file and that
// package has the same name as a loaded package it is an error. If an attempt
// is made to load a package by name and such a package is already loaded it just
// returns that package.
Good to know how conflicting extensions module names are resolved.
// Packages can be unloaded from memory, however they are not completely removed
// until it is possible to do so - i.e. until there are no instances of any module
// within the package in use.
I've hit up against this many times (a bug in Extension Builder stack probably) where I've left a widget demo stack opened, then 'unloaded' the widget's module and then tried loading a recompiled version of the same module, only to have it error loading, because the first build never really unloaded. If you're letting Extension Builder stack manage the test stack generating then this isn't a probably, but I usually wind up with a separate custom tester stack.
// Packages are a zip archive with the following structure:
// <root>/
// manifest.xml
// module.lcm
manifest.xml, module.lcm get auto-generated by extension builder stack
// support/
// <files for the IDE / store etc.>
This is where the module's PNG icons can (optionally) go, there can be two bitmapped icons, old-school regular size and plus one for HiDPI screens. These icons can represent the module in the IDE when no SVGIcon is included in the module.
This is also where a _defaultScript file can (optionally) go, which is a file that can contain multiple pre-written script handlers that can be use with the module, these with appear in the available handlers list in script editor.
// modules/
// <compiled submodule files>
Ah hah! This is where linked sub-modules should go!
// symbols/
// <compiled module debug info>
I HAVE NO IDEA WHAT THIS FOLDER IS! I've never seen it. Maybe it has something to do with debugging symbols/name space? In Foreign Code libraries?
// resources/
// <shared resources>
You can put images that go along with your module or whatever sort of files you want to include here.
OXT SVGIcons loader thing stores tab-sep-value files here where the module can always find them.
// code/
// <compiled foriegn code>
This is where foreign code library binaries go, they go in a sub-folders name by platform+architecture.
// source/
// <original source code>
Usually I have a single source file at the root level, but maybe this is meant for source for any sub-modules?
// docs/
// <docs tree>
This is where the 'guide' folder would go for your module.
// There is either a widget or a library node. Widgets can have properties and events,
// libraries only handlers.
There's also a third kind for language modules ( the Builder language can be expanded)
This info should be in the XT Builder guide.
