We should probably document all the supported options somewhere central.
I'd suggest this is done as comments at the top of the config file.

Shouldn't this comment be updated to reflect the new arguments being passed to abi-compliance-checker?

Spelling: abi-complience-checker -> abi-compliance-checker

Code style: yaml.load( open(localMetadataPath) )

Could we follow the pattern from BuildSpecs here (which is similar, except it uses separate files per project/platform/etc)

Also, i'm wondering if this module should be called something different to follow the convention of BuildSpecs (although admittedly this could be used for other things as well), perhaps something like ToolingSettings?

Unless 'default' means something special to a YAML indexer, won't this code fail to pick up the defaults?

Won't this lead to platform keys being imported into the configuration/settings dict we return?

can you rephrase this? I don't get it what do you want. Is it just renaming the function? or the filename?

hopefully this solotion is general enough to be used for more things.

this works just fine. see line18 here we add default to the beginning, so the dict is initialized with the values of default entry. tested it for akonadi ( default values should been returned) and akonadi-search (special values are returned)

yepp this is a side-effect, but it is just, that the dict has more entries.
Where do I get a list of platforms to strip those keys out afterwards? In helpers/check-platform.py the dict has this None:MacOSX entry (just add a MacOSX:MacOSX entry) - otherwise it is called allPlatforms :D should we move this to helperslib so we can access it from both places?

The first paragraph was referring to the function name. Usually we've followed a pattern of Class.load( file ) or equivalent. Settings.settings( ) doesn't really describe what it does (which the pattern of BuildSpecs does)

For the second paragraph, I was referring to the filename (which python treats as the module name).

Based on the code, I agree it should be usable for other things.

I see, okay. I didn't see that at first as it was under the sorting all entries comment.
Could you move the comment beside it to it's own line above entries.insert() to make this clearer?

That map in check-platforms is more to map things to an operating system.
In theory platform names can be any string and there isn't any rules around what is valid/invalid.

I'd suggest perhaps that the YAML gets structured something like this to solve this:

"kde/pim/akonadi-search":
  general:
    gcc_options:
     - "-std=c++11"
     - "-fPIC"
     - "-DQT_NO_KEYWORDS"
  "SUSEQt5.10":   # or overwrite the setting for one specific platform
    gcc_options:
     - "-bla"

well I used a more elegant solution and used "*" entry in yaml file, than we don't need a special entry.