[PATCH v5 3/5] env: Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

Hi Tom,

On Tue, 5 Oct 2021 at 09:52, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Oct 05, 2021 at 09:33:18AM -0600, Simon Glass wrote:
> > Hi Wolfgang,
> >
> > On Tue, 5 Oct 2021 at 08:56, Wolfgang Denk <wd at denx.de> wrote:
> > >
> > > Dear Simon,
> > >
> > > In message <CAPnjgZ1tRi5SsqU0K8HXgj-4xCs7i9TLX4Mj0_D=Cpj8BAn32w at mail.gmail.com> you wrote:
> > > >
> > > > > > Add a feature that brings in a .env file associated with the board
> > > > > > config, if present. To use it, create a file in a board/<vendor>/env
> > > > > > directory called <board>.env (or common.env if you want the same
> > > > > > environment for all boards).
> > > > >
> > > > > This should be no exclusive "or" here. If a common.env exists, it
> > > > > should be used for all boards, and if additionally one ore more
> > > > > <board>.env files exist, these should ALSO be applied to the
> > > > > respective boards.
> > > >
> > > > Is it not enough to use #include in the main file? We have a similar
> > > > feature with the u-boot.dtsi files and in that case we only choose the
> > > > most specific.
> > >
> > > 1) This requires that the .env files are run through CPP, which is
> > >    only added in a later patch.
> >
> > OK perhaps I should just merge the patches. It is a bit artificial
> > having two and it seems that people agree we need the += syntax.
>
> It's important to maintain bisectability, yes.  But functionality
> should be evaluated at the end of the series, not intermediate steps.  I
> don't have a strong opinion either way on if these two patches are
> merged, or not.  So on a similar note, all of the feedback about the
> current env documentation is good and helpful, but I think a txt -> rST
> then enhance the rST makes the most sense so that we don't "hide"
> improvements within the migration.

OK. I added Wolfgang's comments in the patch where he made them but
will split them out.

Regards,
Simon