Define what is described by the "model instance file": JSON or DSL

[ruspl-afed]

The current metamodel should be discussed to clearly define what it stands for.
Later we can add an outcome of this discussion as a documentation for the metamodel.

• ToolchainFile is ...
• Toolchain is ...
• Tool is ...
  and so on

[Kummallinen]

I have some draft documentation for this, I will work on publishing over the weekend. There's some reasoning behind the choices made in the prototype so far included

[ruspl-afed]

I expect this to be the most "discussion-intensive" part.
For example I consider Tool in Chain entity more like Calling the Tool of the given version with given options , i.e. it may have a reference to reusable Tool entity.

[Kummallinen]

One of my aims was to ensure options can be defined at a toolchain level not just a tool level, but while allowing customisation of the command line of the option generated per tool. This is a really common use-case that the current CDT definitions cannot properly support.

Allowing tools outside of toolchains doesn't prevent that, but in the majority of cases I think tools should exist in a toolchain and those outside should be the exception.

Versioning of toolchains is tricky to handle. One thing I do want to ensure is that the toolchain definition has no concept of "default values", incorrect use of these in the current system causes lots of issues.

[ilg-ul]

options can be defined at a toolchain level not just a tool level

As you know, the GME toolchain settings support this, but the implementation is tricky and inconsistent, since the 'common options' do not apply to all tools in the toolchain, but only to compilers/linker, and do not apply to tools processing secondary targets, like converting to hex, generating listings, etc.

[Kummallinen]

options can be defined at a toolchain level not just a tool level

As you know, the GME toolchain settings support this, but the implementation is tricky and inconsistent, since the 'common options' do not apply to all tools in the toolchain, but only to compilers/linker, and do not apply to tools processing secondary targets, like converting to hex, generating listings, etc.

This is one of my main requirements to solve. The current prototype allows options at a toolchain level but requires the tool to explicitly "inherit" the option, the "inherit" method also allows customisation of the command line generation attributes.

[ruspl-afed]

explicitly "inherit" the option
This is much closer to a "composition", as "inheritance" works a bit another way. Probably you want to reuse an option definition for particular Tool in the Toolchain? This is usually modeled via "stereotype" of the tool.

[Kummallinen]

The reason I quoted "inherit" is because it isn't inheritance. I'm not sure of the exact nomenclature to describe it model wise.

The option should only really exist in the toolchain, the tool just has a reference to it & some customisation of specific attributes.