Can't specify all project-options in imported yaml

[Laurens Miers]

I tried to create a setup where the majority of project settings are moved to a 'base.yml' which gets imported by a unit-test specific 'project.yml':

# base.yml
:project:
    :build_root: _build_ceedling
    # Imagine the rest of the project settings here

This gets imported by project.yml:

:import:
    - "base.yml"

# Some project specific stuff here

However, this produces an error due to the 'import' section only being handled after we already tried to access fields in the config hash related to project-settings.
I'm guessing this issue is not only limited to :build_root: but it serves to illustrate the problem.

Basically, ceedling implies several project-settings (and possibly others?) to be already set before starting to merge the imports.
This is seen inside the setupinator.rb setup-function, which calls populate_cmock_defaults as one of its first calls.
But this presumes :build_root: is already set:
https://github.com/ThrowTheSwitch/Ceedling/blob/master/lib/ceedling/configurator.rb#L102

But merge_imports is only called after we populated these default settings, so :build_root: must be part of the project.yml already.

I tried a 'fix' by moving the merge_imports to the start of the do_setup function in setupinator. It seemed to work but unsure if this does not impact other stuff/assumptions?

I did find another way of doing it by using the mixin project files feature inside a rakefile:

# rakefile
ENV['CEEDLING_MIXIN_PROJECT_FILES']="#{File.dirname(__FILE__)}/project_base.yml"

mixin project files import/merging happens already in load_project_files of the setupinator (called before do_setup):
https://github.com/ThrowTheSwitch/Ceedling/blob/master/lib/ceedling/setupinator.rb#L14

DISCLAIMER: It could be that it is a 'feature' not to have all settings be supported in the :import: section but a list of non-supported ones could be interesting in that case? But I'm unsure how such a list can be produced reliably without skimming the source-code manually. Or am I misusing the :import: feature and mixing is the way to go here (it already works so probably it is)?

[Mark VanderVoord]

Did you attempt this with the Release Candidate or the previous released gem?

[Laurens Miers]

Tested with v0.31.1, latest master (134496c).
Also checked out test/ceedling_0_32_rc (3ba12fa) and has the same behaviour.
All three still have the merge_imports after populate_defaults is called so makes sense I think the behaviour is the same.
But as stated, don't know if this is really an issue, could be wrong expectations.

I tried writing a spec-test for the setupinator to illustrate the situation but got into problems with mocking the file-reads and such, but haven't written a lot of ruby tests so very likely a lack of knowledge on my part.
Is there a preferred way of handling this in Ceedling tests/ruby/... ?
EDIT: Using Tempfile seems like a sane option? https://rubyapi.org/o/Tempfile

[Michael Karlesky]

@laurensmiers Rake has been very good for Ceedling. I doubt Ceedling would exist without it. But, over a lot of years it's become clear that it limits Ceedling in a variety of ways, large and small, directly and indirectly. One of those indirect limits is how configuration gets loaded, merged, etc.

0.32 to be released soon begins the process of removing Ceedling's dependence on Rake. When we make a little more progress on this, it will become possible to handle many more project file variations at startup. I can envision a scenario where, with the appropriate command line construction, you could load multiple YAML project files, and the order on the command line would dictate how they are merged. This would all happen before any configuration within them is actually processed. How does sound?

I realize this does not address your immediate need. Of course, you'd much prefer this all to work without extra tools (or modifying source as you have for that matter). That said, in the past, I have worked around problems like you're detailing using file templating / expansion tools. Using this approach you'd create and manage template files that import the common and variable configuration sections to produce a handful of complete project files or some clever set of option files that filled in the gaps Ceedling is imposing on you. Not sure if this could work for you, but it's a viable workaround that can be well managed with a small amount of automation and project environment documentation.