alire-project / alire

Command-line tool from the Alire project and supporting library
GNU General Public License v3.0
278 stars 49 forks source link

Generate config file for use in shell-scripts or Makefiles #1155

Open RREE opened 2 years ago

RREE commented 2 years ago

I propose to have a 4th kind of generated config file for the use in shell scripts and Makefiles. In many projects the build of an Ada program is only one of several steps. The subsequent steps have to have the possibility to refer to some of configuration values of the Ada project.

I created a patch to Alire (generate_shell.zip ) that first has to be activated ( [configuration] generate_shell = true) and the generated file can then be read by the post-build actions.

Fabien-Chouteau commented 2 years ago

That sounds like a good idea. Can you open a pull-request with the changes?

RREE commented 2 years ago

As explained in the PR I don't think anymore it is a very useful feature.

Perhaps it would be more useful if alr config --get/--list showed the entries of [configuration] and [configuration.values], too. Shell scripts can then query alr for the needed parameters.

mosteo commented 2 years ago

Sounds sensible, @RREE. If eventually you have a use case please describe it here to help shaping the feature better.

Fabien-Chouteau commented 2 years ago

Perhaps it would be more useful if alr config --get/--list showed the entries of [configuration] and [configuration.values], too. Shell scripts can then query alr for the needed parameters.

We have this bad issue that alr config and [configuration] (a.k.a. crate configuration) are two different things...

RREE commented 2 years ago

The use case at thand is the following: I port the examples one by one from AVR-Ada to the new AVRAda_Examples project.

After generating the elf binary (with alr build/exec) you have to convert it to a hex file and eep (for the EEPROM part) with avr-objcopy before you can upload it to the device with avrdude. I am used to achieve that with generic rules in a Makefile. At least avrdude must know the name of the actual chip. The MCU name is stored in alire.toml as a configuration value avrada_rts.AVR_MCU. I currently extract that value with the help of awk, it would be much more elegant if I could read it as output of alr config --get avrada_rts.avr_mcu.

Most sample apps do not work on all AVR MCUs. Even the simple Uart_Echo requires an internal U(S)ART which is missing on the attiny85, once popular as Digispark. Here it would help if each example could set the configuration value in alire.toml with a command like alr config --set avrada_rts.avr_mcu atmega328p

Currently, I manually edit alire.toml for setting the MCU and comment and uncomment the sample programs that I want to test. Perhaps my setup is wrong. I have the 10 - 15 sample programs in a single crate (comparable to pico_examples). The sample apps have to be compiled and programmed with different parameters, however. An alternative setting would be to dedicate a separate crate per sample app and keep them still a single github project. But even then I need alr config --get <crate configuration value>

mosteo commented 2 years ago

For extracting information from the manifest, everything is already shown by alr show. Perhaps we can add some switch to dump configuration information in a more parsable format, and so there's no confusion with alr config.

Here it would help if each example could set the configuration value

Without really understanding the finer details of your case, you already can set the values in another crate, so I guess you're refering to another kind of feature.

An alternative setting would be to dedicate a separate crate per sample app and keep them still a single github project.

This would alleviate the need to comment/uncomment things. You could simply enter each sample project subdir and build.

But even then I need alr config --get

If this value is specific per example, why is it being set elsewhere? This is the part I don't understand, I think I'll have to check your repos.

Fabien-Chouteau commented 2 years ago

alr show --crate-config seems like an option.

RREE commented 2 years ago

For extracting information from the manifest, everything is already shown by alr show. Perhaps we can add some switch to dump configuration information in a more parsable format, and so there's no confusion with alr config.

As far as I can see there is no output of [configuration] or [configuration.values] when calling alr show.

Here it would help if each example could set the configuration value

Without really understanding the finer details of your case, you already can set the values in another crate, so I guess you're refering to another kind of feature.

I was thinking about setting a configuration value in the current alire.toml via command line, e.g. alr config --set.

An alternative setting would be to dedicate a separate crate per sample app and keep them still a single github project.

This would alleviate the need to comment/uncomment things. You could simply enter each sample project subdir and build.

But even then I need alr config --get

If this value is specific per example, why is it being set elsewhere? This is the part I don't understand, I think I'll have to check your repos.

I want to postprocess the generated binary, mostly I want to upload it to the target board. I have some generic rules for that purpose in my Makefile:

# Program the device.
%.prog: %.hex %.eep
    $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH)$*.hex

# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
    $(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@

%.eep: %.elf
    -$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
    --change-section-lma .eeprom=0 -O $(FORMAT) $< $@

and the $(AVRDUDE_FLAGS) must contain the name of the MCU as some of the switches depend on the actual MCU.

AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER) $(AVRDUDE_NO_VERIFY) $(AVRDUDE_VERBOSE) $(AVRDUDE_ERASE_COUNTER)

The MCU, however, is set in alire.toml: [configuration.value] avrada_rts.AVR_MCU = "atmega328p". I currently extract that value with an awk one-liner in my Makefile:

MCU := $(shell awk -F= '{IGNORECASE = 1} /^ *AVRADA_RTS.AVR_MCU/ {print $$2;}' ../alire.toml | xargs)

That seems awkward and I'd prefer a command like alr config --get avrada_rts.avr_mcu or alr show --crate-config avrada_rts.avr_mcu

Alternatively I could set the MCU in my Makefile directly and use awk to copy the value to alire.toml.

mosteo commented 2 years ago

As far as I can see there is no output of [configuration] or [configuration.values] when calling alr show.

This is what I see e.g. for rp2040_hal (Config set lines):

$ alr show rp2040_hal=2.0
rp2040_hal=2.0.0: Drivers and HAL for the RP2040 micro-controller family
Origin: commit e7b64... from https://github.com/JeremyGrosser/rp2040_hal.git
Properties:
   Author: Jeremy Grosser
   Config set: atomic {Backend := armv6m}
   Config set: cortex_m {core := m0p}
   Config type: Flash_Chip : Enum (w25qxx, generic_qspi, generic_03) default: 'w25qxx'
   Config type: Interrupts : Enum (hal, bb_runtimes) default: 'hal'
   Config type: Use_Startup : Boolean default: 'TRUE'
RREE commented 2 years ago

These are configuration variables defined and set in the same crate. (which btw seems a bit strange for a HAL as it should be set in application).

I do the following steps:

$ alr get rp2040_hal
$ cd rp2040_hal_1.6.0_548c3884
$ alr show

None of the [configuration] values is shown.

If I checkout pico_bsp which depends on rp2040_hal and which sets a configuration value

[configuration.values]
[configuration.values.rp2040_hal]
Flash_Chip = "w25qxx"

I concede that the config value is shown

$ alr show
pico_bsp=1.6.0: Board support package for Raspberry Pi Pico
Origin: path /data/home/re/Devel/pico_bsp_1.6.0_57968137
Properties:
   Author: Jeremy Grosser
   Config set: rp2040_hal {Flash_Chip := w25qxx}
   Configuration: no modifiers

In my examples for AVR-Ada I use a different syntax for setting configs

[configuration.values]
avrada_rts.AVR_MCU = "atmega328p"
avrada_rts.Clock_Frequency = "16000000"

Perhaps that is reason why they aren't shown. I will check.

RREE commented 2 years ago

OK, it is shown even with the current syntax for setting the value. I somehow missed that, sorry.

$ alr show
avrada_examples_uart_echo=0.1.0-dev: Sample application in Ada for AVR microcontrollers, echo UART input
Origin: path /data/home/re/Devel/AVRAda_Examples/uart_echo
Properties:
   Author: Rolf Ebert
   Config set: avrada_rts {AVR_MCU := atmega328p, Clock_Frequency := 16000000}

But then, extracting the value from this output is even more complicated than reading it directly from alire.toml

Fabien-Chouteau commented 2 years ago

@RREE alr show already has a --jekyll switch that will output information in Jekyll static website format:

alr show rp2040_hal --jekyll                                                                                                                        [16:01]
---
layout: crate
crate: "rp2040_hal"
authors: ["Jeremy Grosser"]
maintainers: ["Jeremy Grosser <jeremy@synack.me>"]
licenses: ["BSD-3-Clause"]
websites: ["https://pico-doc.synack.me/"]
tags: ["embedded",
"nostd",
"rp2040",
"raspberrypi",
"drivers"]
version: "2.0.0"
short_description: "Drivers and HAL for the RP2040 micro-controller family"
dependencies: [{crate: "atomic", version: "~0.4"},
{crate: "cortex_m", version: "~0.5"},
{crate: "gnat_arm_elf", version: "^12"},
{crate: "hal", version: "~0.3"},
{crate: "usb_embedded", version: "~0.3"}]
configuration_variables: [{name: 'Flash_Chip', type: 'Enum (w25qxx, generic_qspi, generic_03)', default: "w25qxx"},
{name: 'Interrupts', type: 'Enum (hal, bb_runtimes)', default: "hal"},
{name: 'Use_Startup', type: 'Boolean', default: "TRUE"}]
configuration_values: [{crate: 'atomic', settings: [{name: 'Backend', value: "armv6m"}]},
{crate: 'cortex_m', settings: [{name: 'core', value: "m0p"}]}]
---

All the stuff between the two --- line is json data, so very easy to parse.

RREE commented 2 years ago

Thanks for the hint about --jekyll. But parsing json is not that much easier than parsing toml. I just want to extract a single value for using it in a Makefile. My current current work-around with the mentioned awk one-liner works well enough