[U-Boot] [RFC PATCH] tools/buildman: Add env-flags section support

[Tom Rini]

On Fri, Aug 22, 2014 at 07:45:42PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 22 August 2014 07:27, Tom Rini <trini at ti.com> wrote:
> > In some cases (such as building little endian MIPS with the ELDK
> > toolchain) you need to set a variable in the environment in order for
> > the build to complete.  Add env-flags, similar to make-flags, to allow
> > for this.
> >
> > Signed-off-by: Tom Rini <trini at ti.com>
> > ---
> >
> > I have this as RFC since GetEnvSettings is a copy/paste of
> > GetMakeArguments and that tells me there must be a pythonic way of
> > extending / renaming GetMakeArguments to take the dict to work from as
> > an argument.  And as per my other email, ${variable-board} doesn't work
> > so the README is actually incorrect.
> >
> >  tools/buildman/README           |   24 +++++++++++++++++++++++
> >  tools/buildman/builderthread.py |    6 ++++++
> >  tools/buildman/toolchain.py     |   40 +++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 70 insertions(+)
> >
> > diff --git a/tools/buildman/README b/tools/buildman/README
> > index d4e8404..b513b81 100644
> > --- a/tools/buildman/README
> > +++ b/tools/buildman/README
> > @@ -676,6 +676,30 @@ It is expected that any variables added are dealt with in U-Boot's
> >  config.mk file and documented in the README.
> >
> >
> > +Providing key/value pairs to the environment
> > +============================================
> > +
> > +U-Boot's build system supports a few environment variables (such as
> > +CONFIG_USE_PRIVATE_LIBGCC) which affect the build product. These flags can be
> > +specified in the buildman settings file. They can also be useful when building
> > +U-Boot against other open source software.
> > +
> > +[env-flags]
> > +mipsel-flags=CONFIG_USE_PRIVATE_LIBGCC=y
> > +qemu_mipsel=${mipsel-flags}
> > +maltael=${mipsel-flags}
> > +pb1000=${mipsel-flags}
> > +dbau1550_el=${mipsel-flags}
> > +
> > +This will set 'CONFIG_USE_PRIVATE_LIBGCC' to 'y' in the environment for
> > +qemu_mipsel, maltael, pb100 and dbau1550_el.  A special variable ${target} is
> > +available to access the target name (qemu_mipsel, maltael, pb1000 and
> > +dbau1550_el in this case). Variables are resolved recursively.
> > +
> > +It is expected that any variables added are dealt with in U-Boot's
> > +config.mk file and documented in the README.
> 
> This should be equivalent to adding them on the 'make' command line.
> Is there somethign else?

Well ble-arg.  I thought I had tried this already but apparently not.
[make-flags]
qemu_mipsel=CONFIG_USE_PRIVATE_LIBGCC=y
maltael=CONFIG_USE_PRIVATE_LIBGCC=y
pb1000=CONFIG_USE_PRIVATE_LIBGCC=y
dbau1550_el=CONFIG_USE_PRIVATE_LIBGCC=y

Gets me building all MIPS boards, so I'm just going to stick with that
and we can drop env-flags.

[snip]
> > +        self._env_flags['target'] = board.target
> > +        arg_str = self.ResolveReferences(self._env_flags,
> > +                           self._env_flags.get(board.target, ''))
> > +        args = arg_str.split(' ')
> > +        i = 0
> > +        while i < len(args):
> > +            if not args[i]:
> > +                del args[i]
> > +            else:
> > +                i += 1
> > +        return args
> 
> Yes this could go in a common function. You can pass the dictionary to
> it, and updates within the function will update the dictionary.
> 
> BTW I suppose we can replace the last 8 lines with something like:
> 
> return [arg for arg in arg_str.split(' ') if arg]

Being a middling at best python person, how common is it to condense
things down that far?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140823/b7297ae8/attachment.pgp>