On 25/10/2019 19:28, Gedare Bloom wrote:
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.
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.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
