Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
> On 22 Jul 2021, at 6:53 pm, Sebastian Huber > wrote: >> On 22/07/2021 10:47, Chris Johns wrote: >>> On 22/7/21 6:37 pm, Sebastian Huber wrote: >>> On 22/07/2021 10:33, Chris Johns wrote: >> and so the arch part is not >> really needed. My concern is this type code ... >> >> https://git.rtems.org/rtems_waf/tree/rtems.py#n758 >> >> that breaks. Is this an issue? I think a single `/` in a BSP or family is >> cleaner. > Why is this an issue? This BSP family stuff is local to the RTEMS build > system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. >>> You mean that maybe someone wants to build an application or library for a >>> BSP >>> family? I guess this is currently not supported, but you could do this with >>> the >>> "bsps/powerpc/motorola_powerpc" approach. >> Yes it could happen and this is where the symmetry and the existing code >> matters. For example with `bsps/motorola_powerpc` the code can be easily or >> cleanly extended by looking for `bsps` as an arch and knowing that is a >> `family`. Otherwise the error is `invalid arch/bsp` and then you need check >> two >> lengths etc etc. > > If you want to add this feature, then you have to update the code anyway. You > have to figure out which BSPs belong to a family for example. Yeap. It is a detail but I am looking ahead. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 10:47, Chris Johns wrote: On 22/7/21 6:37 pm, Sebastian Huber wrote: On 22/07/2021 10:33, Chris Johns wrote: and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Why is this an issue? This BSP family stuff is local to the RTEMS build system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. You mean that maybe someone wants to build an application or library for a BSP family? I guess this is currently not supported, but you could do this with the "bsps/powerpc/motorola_powerpc" approach. Yes it could happen and this is where the symmetry and the existing code matters. For example with `bsps/motorola_powerpc` the code can be easily or cleanly extended by looking for `bsps` as an arch and knowing that is a `family`. Otherwise the error is `invalid arch/bsp` and then you need check two lengths etc etc. If you want to add this feature, then you have to update the code anyway. You have to figure out which BSPs belong to a family for example. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 6:37 pm, Sebastian Huber wrote: > On 22/07/2021 10:33, Chris Johns wrote: and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. >>> Why is this an issue? This BSP family stuff is local to the RTEMS build >>> system. >> Currently. It is about the symmetry of the naming and how it would look from >> outside. Nothing more. > > You mean that maybe someone wants to build an application or library for a BSP > family? I guess this is currently not supported, but you could do this with > the > "bsps/powerpc/motorola_powerpc" approach. Yes it could happen and this is where the symmetry and the existing code matters. For example with `bsps/motorola_powerpc` the code can be easily or cleanly extended by looking for `bsps` as an arch and knowing that is a `family`. Otherwise the error is `invalid arch/bsp` and then you need check two lengths etc etc. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 10:33, Chris Johns wrote: and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Why is this an issue? This BSP family stuff is local to the RTEMS build system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. You mean that maybe someone wants to build an application or library for a BSP family? I guess this is currently not supported, but you could do this with the "bsps/powerpc/motorola_powerpc" approach. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 4:44 pm, Sebastian Huber wrote: > On 22/07/2021 08:37, Chris Johns wrote: >> On 22/7/21 4:20 pm, Sebastian Huber wrote: >>> On 22/07/2021 02:39, Chris Johns wrote: On 22/7/21 5:22 am, Sebastian Huber wrote: > BSP family and BSP variant names may be equal. This prefix avoids > ambiguity in the enabled-by expressions. > --- > wscript | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/wscript b/wscript > index f27dba6831..b7a0412150 100755 > --- a/wscript > +++ b/wscript > @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, > top_group, variant): > conf.env["ENABLE"] = [ > get_compiler(conf, cp, variant), > arch, > - arch_family, > + "family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. >>> >>> Yes, this is good and matches with our directory layout. I checked it in >>> with >>> this change. >>> >>> We could also merge the default-by-family and default-by-variant lists with >>> this >>> approach, >> >> I am not sure. My initial reaction was "yes" but how would different settings >> for a BSP and a family be handled? I am assuming a BSP variant setting is >> able >> to override a family setting. Is that possible if they are merged? > > Yes, a BSP variant would have higher priority, this is enforced by the search > order: > > for default in self.data["default-by-variant"]: > if OptionItem._is_variant(default["variants"], variant): > value = default["value"] > break > for default in self.data["default-by-family"]: > if OptionItem._is_variant(default["families"], family): > value = default["value"] > break Then I am fine with the merging back to a single default-by-variant. >>> for example: >>> >>> diff --git a/spec/build/bsps/optconsolebaud.yml >>> b/spec/build/bsps/optconsolebaud.yml >>> index 4b0869beca..0233fdd61b 100644 >>> --- a/spec/build/bsps/optconsolebaud.yml >>> +++ b/spec/build/bsps/optconsolebaud.yml >>> @@ -6,13 +6,10 @@ build-type: option >>> copyrights: >>> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) >>> default: 115200 >>> -default-by-family: >>> -- value: 9600 >>> - families: >>> - - powerpc/motorola_powerpc >>> default-by-variant: >>> - value: 9600 >>> variants: >>> + - bsps/powerpc/motorola_powerpc >> >> Oh I think my patch piece may have been wrong. This has two `/` and so three >> components. We _must_ have unique family names > > The BSP family names are just names in an architecture directory, so this rule > would be not enforced by the directory layout. Sure and that fine. >> and so the arch part is not >> really needed. My concern is this type code ... >> >> https://git.rtems.org/rtems_waf/tree/rtems.py#n758 >> >> that breaks. Is this an issue? I think a single `/` in a BSP or family is >> cleaner. > > Why is this an issue? This BSP family stuff is local to the RTEMS build > system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 08:37, Chris Johns wrote: On 22/7/21 4:20 pm, Sebastian Huber wrote: On 22/07/2021 02:39, Chris Johns wrote: On 22/7/21 5:22 am, Sebastian Huber wrote: BSP family and BSP variant names may be equal. This prefix avoids ambiguity in the enabled-by expressions. --- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index f27dba6831..b7a0412150 100755 --- a/wscript +++ b/wscript @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, top_group, variant): conf.env["ENABLE"] = [ get_compiler(conf, cp, variant), arch, - arch_family, + "family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. Yes, this is good and matches with our directory layout. I checked it in with this change. We could also merge the default-by-family and default-by-variant lists with this approach, I am not sure. My initial reaction was "yes" but how would different settings for a BSP and a family be handled? I am assuming a BSP variant setting is able to override a family setting. Is that possible if they are merged? Yes, a BSP variant would have higher priority, this is enforced by the search order: for default in self.data["default-by-variant"]: if OptionItem._is_variant(default["variants"], variant): value = default["value"] break for default in self.data["default-by-family"]: if OptionItem._is_variant(default["families"], family): value = default["value"] break for example: diff --git a/spec/build/bsps/optconsolebaud.yml b/spec/build/bsps/optconsolebaud.yml index 4b0869beca..0233fdd61b 100644 --- a/spec/build/bsps/optconsolebaud.yml +++ b/spec/build/bsps/optconsolebaud.yml @@ -6,13 +6,10 @@ build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) default: 115200 -default-by-family: -- value: 9600 - families: - - powerpc/motorola_powerpc default-by-variant: - value: 9600 variants: + - bsps/powerpc/motorola_powerpc Oh I think my patch piece may have been wrong. This has two `/` and so three components. We _must_ have unique family names The BSP family names are just names in an architecture directory, so this rule would be not enforced by the directory layout. and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Why is this an issue? This BSP family stuff is local to the RTEMS build system. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 4:20 pm, Sebastian Huber wrote: > On 22/07/2021 02:39, Chris Johns wrote: >> On 22/7/21 5:22 am, Sebastian Huber wrote: >>> BSP family and BSP variant names may be equal. This prefix avoids >>> ambiguity in the enabled-by expressions. >>> --- >>> wscript | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/wscript b/wscript >>> index f27dba6831..b7a0412150 100755 >>> --- a/wscript >>> +++ b/wscript >>> @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, >>> top_group, variant): >>> conf.env["ENABLE"] = [ >>> get_compiler(conf, cp, variant), >>> arch, >>> - arch_family, >>> + "family/" + arch_family, >> "bsps/" + arch_family, >> >> ... as discussed in the other thread? If you are happy with the change as >> shown >> please push. > > Yes, this is good and matches with our directory layout. I checked it in with > this change. > > We could also merge the default-by-family and default-by-variant lists with > this > approach, I am not sure. My initial reaction was "yes" but how would different settings for a BSP and a family be handled? I am assuming a BSP variant setting is able to override a family setting. Is that possible if they are merged? > for example: > > diff --git a/spec/build/bsps/optconsolebaud.yml > b/spec/build/bsps/optconsolebaud.yml > index 4b0869beca..0233fdd61b 100644 > --- a/spec/build/bsps/optconsolebaud.yml > +++ b/spec/build/bsps/optconsolebaud.yml > @@ -6,13 +6,10 @@ build-type: option > copyrights: > - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) > default: 115200 > -default-by-family: > -- value: 9600 > - families: > - - powerpc/motorola_powerpc > default-by-variant: > - value: 9600 > variants: > + - bsps/powerpc/motorola_powerpc Oh I think my patch piece may have been wrong. This has two `/` and so three components. We _must_ have unique family names and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 02:39, Chris Johns wrote: On 22/7/21 5:22 am, Sebastian Huber wrote: BSP family and BSP variant names may be equal. This prefix avoids ambiguity in the enabled-by expressions. --- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index f27dba6831..b7a0412150 100755 --- a/wscript +++ b/wscript @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, top_group, variant): conf.env["ENABLE"] = [ get_compiler(conf, cp, variant), arch, -arch_family, +"family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. Yes, this is good and matches with our directory layout. I checked it in with this change. We could also merge the default-by-family and default-by-variant lists with this approach, for example: diff --git a/spec/build/bsps/optconsolebaud.yml b/spec/build/bsps/optconsolebaud.yml index 4b0869beca..0233fdd61b 100644 --- a/spec/build/bsps/optconsolebaud.yml +++ b/spec/build/bsps/optconsolebaud.yml @@ -6,13 +6,10 @@ build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) default: 115200 -default-by-family: -- value: 9600 - families: - - powerpc/motorola_powerpc default-by-variant: - value: 9600 variants: + - bsps/powerpc/motorola_powerpc - m68k/m5484FireEngine - powerpc/hsc_cm01 - powerpc/beatnik -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 5:22 am, Sebastian Huber wrote: > BSP family and BSP variant names may be equal. This prefix avoids > ambiguity in the enabled-by expressions. > --- > wscript | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/wscript b/wscript > index f27dba6831..b7a0412150 100755 > --- a/wscript > +++ b/wscript > @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, > top_group, variant): > conf.env["ENABLE"] = [ > get_compiler(conf, cp, variant), > arch, > -arch_family, > +"family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] build: Add "family/" prefix to BSP familiy enable
BSP family and BSP variant names may be equal. This prefix avoids ambiguity in the enabled-by expressions. --- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index f27dba6831..b7a0412150 100755 --- a/wscript +++ b/wscript @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, top_group, variant): conf.env["ENABLE"] = [ get_compiler(conf, cp, variant), arch, -arch_family, +"family/" + arch_family, arch_bsp, ] -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
