Implementing a preset option for targets in libraries

[Jotrorox]

This change is (for now) just a proposal: it implements a way to define presets for certain target configurations by the library authors. This is especially useful for developers working with libraries targeting microcontroller boards like the Arduino or ESP32 family. The user won't have to fiddle with those configurations, like what to enable, what to disable, what CPU architecture to use, or whether to not set an entry point.

This, at least in my opinion, provides a huge boost in ease of use without taking away from the customizability of C3 projects. Everything can be overridden by the user by just setting the configuration in the user's project.json file.

I just wanted to put this out here and get some feedback on whether this is wanted or not or how this could be changed for a better dx.

Example manifest.json:

{
  "provides": "arduino",
  "presets": {
    "arduino_uno": {
      "cpu": "atmega328p",
      "target": "elf-avr",
      "opt": "Oz",
      "linker": "builtin",
      "use-stdlib": false,
      "link-libc": false,
      "no-entry": true
    }
  },
  "targets": { ... }
}

Example project.json:

{
  "dependencies": ["arduino"],
  "dependency-search-paths": ["lib"],
  "targets": {
    "pot_fade": {
      "type": "executable",
      "preset": "arduino:arduino_uno",
      "name": "pot_fade",
      "extension": ".elf"
    }
  }
}

[lerno]

Interesting!

[Jotrorox]

The current state of this PR:

• Added preset support for project targets using the library:preset format.
• Presets are resolved from a dependency’s manifest.json, using the configured dependencies and dependency-search-paths.
• Preset references are validated for format and naming, the referenced library must also be listed as a dependency.
• Preset configuration is loaded before the target’s own configuration, so users can still override anything locally in project.json.
• Library manifests can now expose a top-level presets map.
• Library manifests can now expose features, and enabled project target features can apply additional library target configuration. Those features are uppercase constants
• Manifest loading has been factored out so presets can be resolved from both directory libraries and .c3l archives.
• The project schema has been extended to document the new target fields and add 2 missing ones.

I think that should be the most important things that changed.
I would really appreciate some feedback on that changes and the proposal overall :)

[ManuLinares]

Would it be possible to add a few tests?

Maybe a synthetic lib or two in resources/testproject/, some .c3 file in there that uses (or not) the features, and some logic in scripts/tools/ci_tests.sh to test this in the CI (so we validate all platforms).

[Jotrorox]

@ManuLinares Would that be enough testing or should I add more? If I should add more could you please provide one or two ideas of tests you'd like to see. And thanks a lot for the note :)

[ManuLinares]

This looks good.

I would remove all of the weird dashes – (Unicode U+2013) from the codebase but that's a @lerno call

[Jotrorox]

The en-Dashes are used quite a bit around the code base so I thought that they are fine. Of course I could of course remove them if wanted :)

And yeah you are right they can look weird, but I like them quite a bit :3

Just a few lines where they are used (the first few returned by rg $'\u2013'):
lib/std/encoding/codepage.c3: 36, 39, 50
src/compiler/sema_expr.c: 7048, 8387
src/compiler/sema_decls.c: 422, 3713

[ManuLinares]

compiler output is a tool interface, not prose, and should minimize encoding risk, ambiguity, and downstream parsing issues

[Jotrorox]

I removed all occurrences of the en-Dash in my pr and I'd b e open to also create a quick pr removing the other ones in error msgs etc. If this is wanted.