Nested mixins do not seem to work

[msimpson80]

In the "old" ceedlng, we could have options files include other options files

As I understand it, this ability to inlcude extra config has been replaced with mixins, and project.yml allows us to define some mixins that should be enabled automatically.

However, this does not work from within another mixin. As an example, imagine I want to have an application.yml and bootloader.yml, both of which require a particular #define ENABLE_MODEM_XYZ

Ideally I would like to do this:

project.yml:

:mixins:
  :load_paths: 
    - test/mixins

application.yml:

:mixins:
  :enabled: [modemxyz]

bootloader.yml:

:mixins:
  :enabled: [modemxyz]

modemxyz.yml

:defines:
  :common: &common_defines_modemxyz
    - CONFIG_MODEM_XYZ=1  

And then just specifiy:

ceedling --mixin=application or ceedling --mixin=bootloader

However this doesnt work. I can specify modemxyz as enabled in project.yml, but it doesnt work from within other mixins

[msimpson80]

Obviously in the example above i can just add my define in project.yml, but in my actual use case I have multple hardware variants, and will have different mixins for each, and want to reuse definitiions between them

[msimpson80]

I see from the documentation this is expected:

Ceedling only recognizes a :mixins section in your base project configuration file. A :mixins section in a mixin is ignored. In addition, the :mixins section of a base project configuration file is filtered out of the resulting configuration.

This makes me sad, as it means the mixins is less powerfull than the :import: in old ceedling.

Yes, I can specifiy multiple mixins, but that makes usage more complicated and error prone.

[mvandervoord]

For the 1.0.x releases, we slimmed down many of the problematic features that were leading to undefined issues. The plan is to walk these features back into future releases, but with a watchful eye towards doing them correctly.

In the original implementation, there were a lot of open questions about the order of import, multiply-included imports, and circular imports. All of these caused problems for people and the failures were cryptic.

Therefore, at the moment, mixins doesn't include chaining from one mixin to another.

I'd love to hear more about usecase(s) where this is helpful though. If you don't mind, can you talk a little about your setup and how this was an advantage? I'm not against reintroducing this feature... but if we do, I definitely want to make sure it addresses people's needs without the previous issues.

[msimpson80]

Thanks for the reply - I thought those might have been the issues you would face. And I definitely appreciate removal of some of the more problematic features in order to provide a stable, quality release for 1.x.

I will try and provide a more detailed description of my ideal setup - but in summary it would be something like this:

1. A collection of feature based mixins that enable feature flags (as defines), add appropriate include, source, test dirs etc. These might enable software features, or perhaps allow selection of different hardware variants - eg different modem types
2. A collection of "product" mixins, that import multiple feature mixins as required for each product we build. These might also differentiate between bootloader and application

I might also want several levels in the heirachy - so for instance if I am including support for air quality measurements, I might want to import a mixin air_quality.yml that in turn includes individual mixins for different sensors.....

The key for me is I want to be able to do :

ceedling --mixin=productVariantA

rather than

ceedling --mixin=featureA --mixin=featureB --mixin=featureC --mixin=featureD

I guess I could provide a per product script, but it becomes more difficult to manage.