Add embeds, file sets

[mwoehlke]

Add attributes to support the C/C++ #embed directive which was recently standardized. Introduce a 'file set' object to the schema, with corresponding file_sets attribute. These are being combined mostly for the sake of the corresponding schema version bump, but 'embeds' are one of the supported file set types.

For now, file sets are primarily informative, offering a way for certain tools to match #include/#embed directives in consumer's sources to specific components, which is useful for various sorts of correctness validation ("linting").

[nickelpro]

cc @dcbaker @grafikrobot @cfrankmiller

embeds I think should be fine, it's a direct analogy for includes for the new feature, mapping to the --embed-dir flag instead of -I.

Personally I'm fine with filesets going in. No one had strong objections to purely informative file sets. To be clear, this is in support of tools like link-what-you-include, which want to be able to map specific headers to specific components. It's not a build-correctness feature at the moment, for emission or consumption.

I'll hold off on approval in case anyone wants to raise strong objections.

[mwoehlke]

Yeah, reasoning behind embeds was 1) trying to be proactive rather than reactive for a change, 2) consistency with embeds as a file set type, since we know we want it, and 3) the embeds attribute is a clearer candidate for a version bump, and doing them together means not worrying what sort of version bump file_sets on its own warrants, or likewise if embeds as a file set type was added later.

I was also planning to give this a week or so to "marinate", so we're on the same page there. 🙂

For now, I'm hoping to avoid allowing per-configuration file_sets, but that's something we can add later if it becomes necessary.

[dcbaker]

This all looks good to me.

@nickelpro thanks for mentioning that filesets are for external tools ATM, I've had a string of conflicts with the call for the last couple of months and am a bit out of the loop.

[cfrankmiller]

This looks good from my perspective. I have one slight concern about overloading the name "prefix" that I made a comment on. I think this is clear enough as is but thought I would point it out for discussion. I apologize for bikeshedding.

[cfrankmiller]

The overloaded prefix name makes for some slight weirdness here because this fileset.prefix attribute can contain the @prefix@ string which refers to the package.prefix.

fileset {
  type: "includes",
  prefix: "@prefix@/include",
  files: [ "some_header.h", "some_other_header.h" ]
}

Should we consider renaming this attribute to something like base_dir to avoid any confusion or do you think this clear enough?

[grafikrobot]

I share the concern about prefix. Would it be safe, from a semantic pov, to call it dir (or directory) instead?

[nickelpro]

Now that it's been pointed out, I'm a third on this. Rename to anything else reasonable to avoid the semantic collision of prefix/@prefix (no opinion on what, dir/base_dir/directory all work for me).