GNU bug report logs -
#18057
[PATCH] Find tail.c in srcdir, not builddir
Previous Next
Full log
Message #14 received at 18057 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/23/2014 10:48 AM, Andreas Schwab wrote:
> Bernhard Voelker <mail <at> bernhard-voelker.de> writes:
>
>> On 07/19/2014 05:26 PM, Andreas Schwab wrote:
>>> diff --git a/tests/tail-2/inotify-race.sh b/tests/tail-2/inotify-race.sh
>>> index c25f354..7140871 100755
>>> --- a/tests/tail-2/inotify-race.sh
>>> +++ b/tests/tail-2/inotify-race.sh
>>> @@ -37,7 +37,7 @@ case $(cat gdb.out) in
>>> *) skip_ "can't run gdb";;
>>> esac
>>>
>>> -break_src="$abs_top_builddir/src/tail.c"
>>> +break_src="$abs_top_srcdir/src/tail.c"
>>> break_line=$(grep -n ^tail_forever_inotify "$break_src") || framework_failure_
>>> break_line=$(echo "$break_line" | cut -d: -f1) || framework_failure_
>>>
>>
>> Thanks for the patch.
>> However, what's wrong with $abs_top_builddir?
>
> Is that a serious question?
That's where a good commit message would have spared some time. If you
had mentioned something like this in the commit message:
tail.c lives in srcdir; for users that test in-tree, this happens to be
the same as builddir. But this is not true for a VPATH build, and was
breaking 'make check' with the following error message:
....
then it could have prevented this back-and-forth. The patch looks
correct and necessary to me, but it is always better to give a
maintainer zero excuse for not applying a patch by giving them full
justification up front instead of making them figure out on their own
what you already learned while writing the patch.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 10 years and 301 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.