Attributes in build specification items

[Sebastian Huber]

On 25/10/2019 19:28, Gedare Bloom wrote:
> On Fri, Oct 25, 2019 at 2:35 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> Hello,
>>
>> for the new build system the specification what to build is contained in
>> so called build specification items. The items are files in YAML format
>> and are maintained by Doorstop and a text editor. For example a build
>> specification item for an integer configuration option could look like:
>>
>> active: true
>> build-type: integer-option
>> default: 100000000
>> default-by-variant:
>> - value: 333333333
>>     variant: xilinx_zynq_zc702
>> - value: 666666667
>>     variant: xilinx_zynq_zedboard
>> derived: false
>> header: ''
>> level: 1.5
>> links: []
>> name: BSP_ARM_A9MPCORE_PERIPHCLK
>> normative: true
>> ref: ''
>> reviewed: cKwFFKjf_aPPFZe7fKyxBqYcAqdvU2A0yQaBdhbONQ8=
>> text: |
>>     ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz
>> type: build
>>
>> How do we want to handle optional attributes (e.g. min)? Should we
>> mandate that they are always present in the item file, e.g.
>>
>> min: null
>>
>> or should it be able to omit them and use default values in the wscript,
>> e.g.
>>
>> min = self.data.get("min", None)
>> if min not None:
>>          if value < min:
>>                  error()
>>
>> ?
>>
> I would lean toward mandating that attributes used to configure should
> be present in the item file. This way, the item file is archival with
> respect to the build, and one doesn't need to know/read the wscript to
> understand what was the configuration default value.

Ok, I was also in favour of this approach. I will remove all default 
values from the wscript.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.