[multitop] Add better support for linker scripts (templating)

[pamaury]

Linker files are not preprocessed, which makes it hard to support several tops. In particular, including different files based on the top, or using a different region is very difficult. We currently have a semi-hack where we automatically include the directory of any include-ed file but it still requires that files have the same name which is not always the case.

The ld_library rule is modified to take a new substitution dictionary as input which is subject to location expansion. This allows for example to do in the linker script:

INCLUDE @@MYFILE@@

and then in the BUILD file:

ld_library(
  ...,
  substitutions = {
    "@@MYFILE@@": "$(location //path/to/my/file)",
  },
)

The rest of the commits add some substitutions for the ottf and test_rom, plus a final commit specifically for darjeeling.

Review commit by commit, skip the first which is a squashed version of #25580

[jwnrt]

The rule changes LGTM, thanks

[Razer6]

This looks good to me!

[a-will]

This seems fine, but I'll mention that the convention is to use the C preprocessor for this sort of thing. From a support perspective, bazel's APIs are more likely to change in an incompatible way than the C preprocessor, though the risk likely isn't high for this particular activity.

So for a cpp setup, required variables / definitions / macros would go in a required platform-specific header file, the includes paths specified on the command line would handle selecting the correct header, and you'd process it with the C preprocessor to generate the real / final linker script.

That said, for this simple substitution, you get basically the same thing with even the linker script language's own include command. It's not clear the templates in bazel do more than add another DSL to the list of things to know to work with the project (in addition to the required strings to substitute). /shrug

The critical part in this PR is more the abstraction of the path, which was hard-coded as earlgrey. But top-specific linker search paths, directories dedicated to specific targets, and INCLUDE directives would get the job done too (in the ordinary way embedded projects typically do it).

[pamaury]

This seems fine, but I'll mention that the convention is to use the C preprocessor for this sort of thing. From a support perspective, bazel's APIs are more likely to change in an incompatible way than the C preprocessor, though the risk likely isn't high for this particular activity.

So for a cpp setup, required variables / definitions / macros would go in a required platform-specific header file, the includes paths specified on the command line would handle selecting the correct header, and you'd process it with the C preprocessor to generate the real / final linker script.

That said, for this simple substitution, you get basically the same thing with even the linker script language's own include command. It's not clear the templates in bazel do more than add another DSL to the list of things to know to work with the project (in addition to the required strings to substitute). /shrug

The critical part in this PR is more the abstraction of the path, which was hard-coded as earlgrey. But top-specific linker search paths, directories dedicated to specific targets, and INCLUDE directives would get the job done too (in the ordinary way embedded projects typically do it).

This makes sense, although this is now a bigger project ;) I have created #25908 to investigate this alternative, let's discuss there the details.

[pamaury]

Based on the feedback, I am closing in favor of #25908