On Tue, 15 Aug 2017 10:26:18 +0200 Thomas Huth <th...@redhat.com> wrote:
> On 15.08.2017 10:01, Thomas Huth wrote: > > On 15.08.2017 09:03, Cornelia Huck wrote: > >> On Tue, 15 Aug 2017 07:02:10 +0200 > >> Thomas Huth <th...@redhat.com> wrote: > >> > >>> On 14.08.2017 22:44, Eric Farman wrote: > >>>> How often does one really do a "make clean" ? Rather infrequently, > >>>> as I only stumbled on this today. > >>>> > >>>> Perhaps I have missed the RM variable somewhere, as I see similar syntax > >>>> in some of the tests/tcg/ Makefiles, but I don't see it being set here. > >>>> My configure statement isn't terribly interesting, just enabling debug > >>>> for an s390x target, and as such there's no RM variable in its output. > >>>> I'll trust that Thomas will chime in with where it should have been. > >>>> In the meantime, this does the trick for me. > >>> > >>> RM is one of the variables that should be pre-initialized by Make, and > >>> AFAIK should be used to increase portability (well, it's likely not > >>> important for QEMU since we require a posix-shell like built environment > >>> anyway). > >>> > >>> According to the info page of Make, chapter "10.3 Variables Used by > >>> Implicit Rules": > >>> > >>> `RM' > >>> Command to remove a file; default `rm -f'. > >>> > >>> I've also checked it again and "make clean" works fine here (using GNU > >>> Make 3.82). Which version of Make (and Linux distro) are you using? > >> > >> Interesting. It fails for me with GNU Make 3.82 on my RHEL guest as > >> well. > >> > >>> Anyway, maybe I also simply missed something, so I'm certainly also fine > >>> with the patch to revert it to "rm -f". > >> > >> Given that other bios makefiles use rm -f as well, let's just change > >> back until we figure out what's wrong. > > > > I just discovered that it fails for me as well when I do "make clean" > > from the top directory. So far I was only doing "make clean" after doing > > a "cd pc-bios/s390-ccw" first, and that works fine. Weird. Something > > seems to unset the RM variable in our build system, but I fail to find > > the spot where this happens... > > Ok, just found it: It's this line in rules.mak: > > MAKEFLAGS += -rR > > The parameter -R disables the built-in variables, so RM can indeed not > work here. Sorry, I wasn't aware of that setting yet, so your patch is > indeed the right fix here (or we should maybe define RM in rules.mak, too). The other users are all in tests/tcg/. Would there be value in using the built-in variables generally? (Well, value that outweighs having to go through the qemu build system...)
