I'm beginning to understand the Unix-haters philosophy.  Ponder this:

    $ ls -l
    total 16
    -rw-r--r--    1 jimb     jimb            6 Dec 22 11:30 bar
    -rw-r--r--    1 jimb     jimb            5 Dec 22 11:29 baz
    -rw-r--r--    1 jimb     jimb            0 Dec 22 11:30 'boo'
    -rw-r--r--    1 jimb     jimb            3 Dec 22 11:29 foo
    -rw-r--r--    1 jimb     jimb            0 Dec 22 11:32 'foo bar'
    -rw-r--r--    1 jimb     jimb            8 Dec 22 11:32 qux

Notice those filenames there with quotes and spaces in them.  The
quotes are really part of the filenames.

    $ cat foo
    b*
    $ ls $(cat foo)
    bar  baz

Okay, so the shell does expand wildcards in text introduced by $()
substitutions.

    $ cat bar
    f* b*
    $ ls $(cat bar)
    bar  baz  foo

Okay, so the shell does word breaking, and then wildcard expansion.
(And in that order.  The reverse order would have generated an error,
since there's no file whose name matches the wildcard 'f* b*'.)

    $ cat baz
    'b*'
    $ ls $(cat baz)
    'boo'

Okay, so although we do word breaking and wildcard expansion, we treat
quotes like ordinary characters.  Hmm.  So they don't prevent wildcard
expansion.

    $ cat qux
    'f* b*'
    $ ls $(cat qux)
    ls: b*': No such file or directory
    'foo bar'
    $

And they don't prevent word breaking.

Some of the programs in here want to produce, as output, command-line
arguments for other programs.  And those arguments may contain spaces.
For example, gdb-test-flags might want to generate an argument like

        RUNTESTFLAGS='--target_board=m32r-elf break.exp'

to be passed to 'make check'.  Suppose we call it like this:

  make check $(gdb-test-flags $builddir)

That's no good: the quotes are going to be treated like ordinary
characters.  So the shell will break that output into two words, at
the space before 'break.exp', and then pass the words as two separate
arguments to make, including their single quote characters.  And if
there were wildcard characters in there, all hell would break loose.
How about this:

  make check "$(gdb-test-flags $builddir)"

That will work for the example given.  But gdb-test-flags also wants
to generate no arguments at all if there are no test flags specified
for $builddir.  In the version of the command with the double quotes,
if gdb-test-flags generates the empty string, then 'make check' gets
that empty string as an argument --- which it doesn't like.

We could have gdb-test-flags always generate some assignment, say:

    RUNTESTFLAGS=""

but that would override whatever default is in the Makefile.  Can't we
just get nothing when we want it?

So it seems we must call gdb-test-flags and its friends like this:

  eval "make check $(gdb-test-flags $builddir)"

Here, we substitute the arguments into a double-quoted string, so no
wildcard expansion or word breaking takes place --- yet.  However,
eval will look at the whole string as a fresh command: it will
recognize quotes in the generated text, then do word breaking, then
expand wildcards.  So if gdb-test-flags produces text like this:

    RUNTESTFLAGS='--target_board=m32r-elf break.exp'

then everything will work, and if it produces no text at all, then no
argument will be sent to make at all.

Unbelievable.