Add configuration file support with variable substitution to dmd, dmr, and dmf-get

[Copilot]

Modules can now specify configuration files that are copied during installation. This enables per-module configuration management within the package system with support for variable substitution in configuration paths.

Changes

.dmd format extension

• Syntax: module[@version] [config_path] [custom_dest_name]
• Configuration path is relative to module's config directory
• Optional custom destination filename parameter
• Works with $from directives: dmclk@1.0 mcu/stm32f7.ini $from https://example.com/manifest.dmm
• Supports multiple entries for same driver with different configs from different versions
• Variable substitution: Configuration paths support ${VARIABLE_NAME} syntax for dynamic path resolution

.dmr format extension

• Define configuration directory using config or configs resource key
• Example: config=./configs => ${destination}/${module}/config

dmf-get enhancement

• New --config-dir option specifies where configuration files are copied
• New -D / --define option to define variables for config path substitution
  • Format: -D VAR=value or --define VAR=value
  • Can be used multiple times for multiple variables
  • Variables checked in order: user-defined first, then environment variables
• Looks up config files via .dmr definition, falls back to <module>/config/ if undefined
• Path validation via existing IsPathSafe() mechanism
• Default destination: <config-dir>/<module_name>/<filename>
• Custom destination: <config-dir>/<custom_dest_name>
• Variable substitution works in both source paths and destination names

Usage

# deps.dmd with variable substitution
dmclk@1.0 boards/${BOARD}/config.ini
uart@2.0 boards/${BOARD}/uart.ini ${BOARD}_uart.ini

# Install with config copy and variable definition
dmf-get -d deps.dmd --config-dir ./config -D BOARD=stm32f7

# Multiple variables
dmf-get -d deps.dmd --config-dir ./config -D BOARD=stm32f7 -D VERSION=v1

Implementation details

• Added config and config_dest fields to Dmod_DependencyEntry_t (max 256 chars each)
• Parser handles optional config path and destination filename parameters
• CopyConfigurationFile() resolves config location and copies to module subdirectory by default
• Variable substitution function SubstituteConfigVariables() handles ${VAR} expansion
• Global variable storage for user-defined variables (max 32 variables)
• 7 test cases validate parsing with/without version, custom destinations, and multiple configs (26 total tests)
• Buffer size constants DMOD_MAX_PATH_LEN and DMOD_MAX_CMD_LEN added for consistency

Backward compatible - existing .dmd files without config specifications work unchanged.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Dodać wsparcie dla konfiguracji w dmd, dmr oraz dmf-get</issue_title>
<issue_description>Niektóre moduły mogą zawierać katalog z domyślnymi konfiguracjami. Powinna być możliwość zdefiniowania go w określony sposób w pliku zasobów *.dmr, tak aby następnie można było w pliku *.dmd napisać że chcemy driver X razem z konfiguracją Y, którą dmf-get nam powinien przekopiować w miejsce, które mu wskażemy w parametrach. Czyli np:

dmclk@1.0 mcu/stm32f7.ini

Gdzie to mcu/stm32f7.ini to nazwa pliku w katalogu konfiguracji. </issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Dodać wsparcie dla konfiguracji w dmd, dmr oraz dmf-get #201

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[JohnAmadis]

@copilot zrób jeszcze tak, żeby przy kopiowaniu domyślna docelowa nazwa pliku konfiguracji to było <nazwa_drivera>/<nazwa_pliku> - czyli np z dmclk mcu/stm32f7.ini by powstał plik dmclk/stm32f7.ini

Co więcej powinno się dać wpisać w dmd ten sam driver kilka razy tylko z inna konfiguracja (jeśli by wersja drivera się zmieniła, czyli np pierwszy wpis miał 0.1 a drugi 0.2 - to wtedy weźmy moduł drivera z pierwszego wpisu, a pliki konfiguracyjne z różnych wersji - tak jak w pliku. Czyli można np podać:

dmclk@1.0 
dmclk@0.1 mcu/stm32f7.ini
dmclk@0.2 mcu/high-speed.ini

W takim przypadku używamy drivera w wersji 1.0, konfiguracji stm32f7 z 0.1 oraz high-speed z 0.2

Co więcej powinna być możliwość zmiany nazwy pliku docelowego, np:

dmclk@1.0 mcu/stm32f7.ini clk.ini

Wtedy plik po przekopiowaniu do folderu docelowego powinien mieć nazwę clk.ini (folder o nazwie dmclk wtedy nie jest potrzebny)

[Copilot]

@copilot zrób jeszcze tak, żeby przy kopiowaniu domyślna docelowa nazwa pliku konfiguracji to było <nazwa_drivera>/<nazwa_pliku> - czyli np z dmclk mcu/stm32f7.ini by powstał plik `dmclk/stm3...

Implemented all requested features in commit d7c8816:

1. Default naming: Config files now copy to <module_name>/<filename> (e.g., dmclk/stm32f7.ini)

2. Custom destination: Optional 3rd parameter for custom filename

   • dmclk@1.0 mcu/stm32f7.ini clk.ini → creates clk.ini directly (no subdirectory)

3. Multiple configs: Same driver can be listed multiple times with different versions

   dmclk@1.0                        # Use driver v1.0
   dmclk@0.1 mcu/stm32f7.ini       # Copy config from v0.1
   dmclk@0.2 mcu/high-speed.ini    # Copy config from v0.2
   

All 26 tests pass. Documentation and examples updated.

[JohnAmadis]

@copilot ale jeśli bym jako dest podał mydir/CLK.ini to stworzy folder mydir? Powinno

[Copilot]

Tak, już działa. Kod w linii 975 używa mkdir -p który tworzy wszystkie potrzebne katalogi nadrzędne. Dla mydir/CLK.ini stworzy folder mydir w katalogu config-dir.

[JohnAmadis]

Jeszcze w tych ścieżkach może się przydać variable substitution - żeby można było podać np <tool_dir> albo <cpu_family> w ścieżce wejściowej albo w dst. Ponadto by się przydała nowa zmienna "board-name" która też by mogła być podawana z parametru @copilot

[Copilot]

Komentarz jest niekompletny. Możesz dokończyć myśl? Jakie dokładnie variable substitution chciałbyś mieć w ścieżkach konfiguracji? Na przykład:

• ${module} dla nazwy modułu?
• ${version} dla wersji?
• Zmienne środowiskowe jak ${HOME}?

Podaj przykład jak chciałbyś użyć tej funkcjonalności.

[JohnAmadis]

@copilot Chodzi mi o to, żeby w pliku *.dmd można było użyć zmiennych przekazanych w parametrach komendy, czyli np:

dmclk@1.0 boards/<board_name>.ini

I teraz przy zawołaniu komendy dać:

dmf-get dmclk --board-name stm32f7-discovery 

I to samo ze ścieżką docelową w dmd - żeby też można było w niej użyć tych zmiennych (board-name, tool-name, cpu family, czy co tam jeszcze jest w parametrach takiego)

Z tego co pamiętam, to już gdzieś jest podobny mechanizm w dmf-get przy okazji któregoś pliku

[Copilot]

Przykład nadal jest niekompletny - kończy się na boards/. Możesz podać pełny przykład? Na przykład:

dmclk@1.0 boards/${BOARD_NAME}/config.ini

I wtedy wywołując dmf-get -d deps.dmd --config-dir ./config --define BOARD_NAME=stm32f7 skopiowałby boards/stm32f7/config.ini?

Czy o to chodzi?

[JohnAmadis]

@copilot jaki niekompletny? podałem dmclk@1.0 boards/< board_name >.ini

Sprawdź jak przekazywane są zmienne w innych miejscach - jeśli tam jest w formacie ${BOARD_NAME}, to niech tutaj też będzie w ten sam sposób - byle by było spójne

[Copilot]

Zaimplementowane w commit aacf3ff. Variable substitution używa formatu ${VAR_NAME} zgodnie z istniejącym kodem w .dmr.

Przykład użycia:

dmclk@1.0 boards/${BOARD}/config.ini
uart@2.0 boards/${BOARD}/uart.ini ${BOARD}_uart.ini

Wywołanie:

dmf-get -d deps.dmd --config-dir ./config -D BOARD=stm32f7

Zmienne sprawdzane są w kolejności:

1. User-defined variables (przez -D)
2. Zmienne środowiskowe

Działa zarówno w ścieżkach źródłowych jak i w custom destination names.

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.