In addition to a com_library!(..) this PR introduces com_module!(..). This is the little brother of the original library macro. The com_module!(..) does more or less everything com_library!(..) does except for introducing any global extern functions.
Both of these also support specifying other modules as exportable items. These modules are then recursively gathered for export in the final com_library!(..):
Each COM library must have exactly one com_library!(..) specification.
COM libraries and even other crates can have any number of com_module!(..) specifications.
Intercom itself now has a com_library!(..) where it defines all exported built-in types (Allocator and ErrorStore). This removes the need to hard-code these in the attributes for creation.
The syntax for specifying exported items now includes the item type:
mod some_module {
com_module!(
class ClassA,
class ClassB,
class ClassC,
);
// ...
}
com_library!(
module some_module,
class Another,
)
The actual module hierarchy is not maintained in the type info and will thus be ignored in IDL/C++ generation. Currently all classes must be globally unique within a COM library.
In addition to a
com_library!(..)
this PR introducescom_module!(..)
. This is the little brother of the original library macro. Thecom_module!(..)
does more or less everythingcom_library!(..)
does except for introducing any global extern functions.Both of these also support specifying other
module
s as exportable items. These modules are then recursively gathered for export in the finalcom_library!(..)
:com_library!(..)
specification.com_module!(..)
specifications.com_library!(..)
where it defines all exported built-in types (Allocator and ErrorStore). This removes the need to hard-code these in the attributes for creation.The actual module hierarchy is not maintained in the type info and will thus be ignored in IDL/C++ generation. Currently all classes must be globally unique within a COM library.
Closes #143