[PATCH v2] wscript: Allow substitution outside values

Joel Sherrill joel.sherrill at gmail.com
Thu Apr 14 15:06:24 UTC 2022


On Thu, Apr 14, 2022, 2:56 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 14/04/2022 09:01, Chris Johns wrote:
> > On 14/4/2022 4:21 pm, Sebastian Huber wrote:
> >> On 14/04/2022 04:19, Chris Johns wrote:
> >>> On 14/4/2022 7:47 am, Kinsey Moore wrote:
> >>>> This expands the ability to substitute variables outside the current
> >>>> limitation of values in options to asflags, cflags, cppflags,
> cxxflags,
> >>>> ldflags, and includes. It is possible for all of these flags to
> utilize
> >>>> user-defined information in config.ini, especially for paths to
> external
> >>>> resources.
> >>> Is exposing access to cflags etc vis config.ini something we want to
> allow? It
> >>> seems low level and I am not sure where it may lead up.
> >> The patch allows you to use options in the flags, for example:
> >>
> >> cflags:
> >> - -I${MY_HYPERVISOR_INCLUDE_PATH}
> >>
> >> It makes the build system more flexible with little extra code.
> > Yes it does and I think this is useful however it also lets users set
> options
> > that could break RTEMS or clash with the options we have specified and
> effect
> > RTEMS is subtle or difficult to find ways.
> >
> > A option that defined support for a hyper-visor provides some level of
> control
> > we could verify.
> >
> > I am not against this feature, I am just wondering what it ends up
> giving us and
> > is it worth it?
>
> This patch just adds the ability to use such options. If we want to add
> a particular option which uses this features is another topic. The
> options can perform custom verification steps defined by the option
> build item.
>

The ini file already lets you specify compiler options. There is plenty of
room for the user to enter a randomly broken value. Is there any filtering
on what the user specifies for warning, optimization, or ABI flags?

This just lets you reference something installed elsewhere. Perhaps this
would also help with SoC BSPs which might default to a particular generated
layout file which could be overridden by something in the users environment.

But in this case we have a hosting OS and need its headers and libraries
for the BSP to integrate.

--joel


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list