On Fri, Oct 25, 2019 at 2:35 AM Sebastian Huber
<sebastian.hu...@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.
> --
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
