[OE-core] what's with the loop with "in in" in u-boot.inc?

[Robert P. J. Day]

On Sat, 7 Mar 2015, Gary Thomas wrote:

> On 2015-03-07 10:48, Bernhard Reutner-Fischer wrote:
> > On March 7, 2015 3:04:52 PM GMT+01:00, "Robert P. J. Day"
> > <rpjday at crashcourse.ca> wrote:
> > >
> > >   based on a recent post to this(?) list, i was curious about the
> > > following loop construct in u-boot.inc:
> > >
> > >         for config in ${UBOOT_MACHINE}; do
> > >             for type in in ${UBOOT_CONFIG}; do
> > >                 if [ "${type}"x = "in"x ]
> > >                 then
> > >                     continue
> > >                 fi
> > >
> > >   the words "in in" above don't appear to be a typo, as the next
> > > condition explicitly checks for the value "in" and skips it. what's
> > > the rationale for that? i used "git blame" to examine the commit that
> >
> > for may barf on empty iteration input.
> > One usually uses for i in ${foo} '';
> > and skips i with zero length. Any other is obviously fine, too though so
> > nothing wrong or odd here.
>
> But this code is only executed if ${UBOOT_CONFIG} is non-empty
> so this test is nonsense.
>
> My guess is that the code originally tested for ${UBOOT_CONFIG}
> being empty this way, then the if/then/else was added (look at
> the indentation) and the original test was never removed (which
> does no harm)

  technically, it *is* possible that UBOOT_CONFIG contains a non-empty
string of spaces so, yes, that test still has some technical value
but ... you know ... yuck. movin' on ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================