Open silviooliva opened 1 year ago
@jkrech, @ReinhardKeil, what do you think? The modification should enhance the standard. If you are ok with that, I can take charge of opening the PR.
@silviooliva, thanks for the systematic review of the
@jkrech, I understand your concern, even if the presence of the mandatory elements (and their mandatory attributes) in the standard should provide the set of information ensuring that a pack is working in tools ignoring the meta information.
On the other hand, having such meta information through the environment
element should favor the increase of the number of tools using the Open-CMSIS packs, so making the standard more and more popular.
@jkrech I get your concern. As @silviooliva said, giving flexibility should open doors for newcomers.
Up to each tool owner to check the reusability of its own packs. But let's say that, even if a pack becomes "not portable", it gives at least visibility for the standard.
In other words, as long as the standard is not able to cover all specificities, we need those entry points to keep using it. At least that's my feeling. Maybe time will bring solutions to replace those tool defined items, or they will keep that form because they are real corner cases that a standard should not try to cover. Universality is quite hard to reach 😊
Understood. @silviooliva I did not mean to say that you should not prepare the PR adding environment
more systematically throughout the hierarchy of the description.
I certainly prefer an environment tag being used instead of 'abusing' elements intended for other purposes.
@silviooliva: Thanks for the PR. We had previously added <extensions>
to <component>
upon STMicroelectronic's request.
1. June 2022: v1.7.8
- added extension points description for components as suggested by STMicroelectronics
Are we certain we need both?
The
environment
element is used in the standard atdevice
andpart
level. It may contains child elements that are specific for a development tool (identified by theenvironment
's attribute name). The structure of an element inside theenvironment
is not specified in the xsd schema file, which gives the development tool full control of the element usage.So far, the
environment
can be used in elements:/package/devices/family
/package/devices/family/device
/package/devices/family/device/variant
/package/devices/family/subfamily
/package/devices/family/subfamily/device
/package/devices/family/subfamily/device/variant
/package/parts/part
To me, it should be introduced also at
boards
andcomponents
level since, also for these elements, there could be the need to define some tool-specific information.So my proposal is to extend the standard introducing the
environment
as (optional) child element of the following elements:/package/components/bundle
/package/components/bundle/component
/package/components/component
/package/boards/board