-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Path replacement support and add custom-options
Closes #51
- Loading branch information
1 parent
34566eb
commit bd21188
Showing
13 changed files
with
518 additions
and
212 deletions.
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,121 @@ | ||
# Custom options | ||
|
||
The custom options are key-value pairs specified by the user at runtime that | ||
allow generating different linker scripts from the same input yaml file. | ||
|
||
This is somewhat similar to "conditional compilation" on compiled programing | ||
languages, kind of similar to what would be done in C with build-time defines | ||
handled by the C preprocessor or in Rust with its features. | ||
|
||
## Table of contents | ||
|
||
- [Custom options](#custom-options) | ||
- [Table of contents](#table-of-contents) | ||
- [How does this work?](#how-does-this-work) | ||
- [Usage](#usage) | ||
- [Path replacement](#path-replacement) | ||
- [Example](#example) | ||
|
||
## How does this work? | ||
|
||
The user can provide any number of key-value pairs when using slinky (either via | ||
the CLI or the API) and use them to affect the generation of the linker script | ||
and other files generated by slinky. This pairs will be used by slinky to | ||
perform textual string replacement, affect which entries are emitted, etc. | ||
|
||
## Usage | ||
|
||
In the context of the CLI, the custom options are specified with the | ||
`--custom-options key=value` long flag or the `-c key=value` short flag. | ||
|
||
Multiple options can be set by passing the flag multiple times (i.e. | ||
`-c key1=value1 -c key2=value2 -c key3=value1 -c key2=value3`) or by passing | ||
multiple pairs separated by a comma (`,`) to the same flag (i.e. | ||
`-c key1=value1,key2=value2,key3=value1,key2=value3`) | ||
|
||
Keys are unique. If the same key is given multiple times to the CLI then the | ||
last key-value pair corresponding to this key is used. Values may be duplicated | ||
among different keys. | ||
|
||
Keys must be simple strings, containing only ASCII alphanumeric characters or | ||
underscore characters (`_`). Keys should not start with a numeric character. | ||
Keys should be composed of at least 1 character. This rules are similar to the | ||
ones imposed to C identifiers like variables. The following regular expression | ||
matches this restriction: `[a-zA-Z_][a-zA-Z0-9_]*`. | ||
|
||
If one or more custom option are passed that are not referenced by the input | ||
yaml file then they are simply ignored. | ||
|
||
The following subsections show how this custom options can affect the linker | ||
script generation. | ||
|
||
### Path replacement | ||
|
||
The path replacement feature allows to insert a custom key into a path in the | ||
input yaml and let slinky replace the given key with the passed custom value. | ||
This feature is specially useful when a single yaml file is wanted to be used | ||
among different versions of the same project by changing the build paths. | ||
|
||
slinky searches paths for strings contained within curly braces like `{key}`. | ||
The key and the braces are replaced with the corresponding value to the given | ||
key. Because of this, if a `{KEY}` is used on any path then a custom option pair | ||
containing the given `KEY` must be passed to slinky, otherwise it will refuse to | ||
generate the linker script and emit an error. | ||
|
||
A `{key}` used in path replacement can't cross each component boundary of the | ||
given path (each component being separated by `/`). In other words, something | ||
like `base_path: build/ga{exam/ple}me/` is not valid, but | ||
`base_path: build/{example}/game/`, `base_path: build/ga{example}me/`, | ||
`target_path: build/{example}/game.{version}.elf` are valid. | ||
|
||
#### Example | ||
|
||
Say we have a yaml file like the following: | ||
|
||
```yaml | ||
settings: | ||
base_path: build/{version} | ||
target_path: build/{version}/game.{version}.elf | ||
|
||
segments: | ||
- name: header | ||
files: | ||
- { path: src/rom_header/rom_header.o } | ||
- { path: "asm/{version}/data/ipl3.o" } # needs to be fenced in quotes | ||
- { path: src/entry/entry.o } | ||
|
||
- name: boot | ||
files: | ||
- { path: "src/boot/boot_main_{region}.o" } # needs to be fenced in quotes | ||
- { path: src/boot/dmadata.o } | ||
- { path: src/boot/util.o } | ||
``` | ||
This yaml file requires two custom options to be passed, `version` and `region`, | ||
so if any of those are missing when invoking slinky then it will produce an | ||
error. | ||
|
||
Now we'll list what the each path expands to by using a few custom option | ||
combinations: | ||
|
||
- `--custom-option version=us -c region=ntsc` | ||
- `target_path`: `build/us/game.us.elf` | ||
- `header` segment: | ||
- `build/us/src/rom_header/rom_header.o` | ||
- `build/asm/us/data/ipl3.o` | ||
- `build/us/src/entry/entry.o` | ||
- `boot` segment: | ||
- `build/us/src/boot/boot_main_ntsc.o` | ||
- `build/us/src/boot/dmadata.o` | ||
- `build/us/src/boot/util.o` | ||
|
||
- `--custom-option version=eu1.1,region=pal` | ||
- `target_path`: `build/eu1.1/game.eu1.1.elf` | ||
- `header` segment: | ||
- `build/eu1.1/src/rom_header/rom_header.o` | ||
- `build/asm/eu1.1/data/ipl3.o` | ||
- `build/eu1.1/src/entry/entry.o` | ||
- `boot` segment: | ||
- `build/eu1.1/src/boot/boot_main_pal.o` | ||
- `build/eu1.1/src/boot/dmadata.o` | ||
- `build/eu1.1/src/boot/util.o` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.