[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14517: t/tags-pr12372.sh assumes that etags generates tags for all f
From: |
Stefano Lattarini |
Subject: |
bug#14517: t/tags-pr12372.sh assumes that etags generates tags for all files |
Date: |
Fri, 31 May 2013 11:58:46 +0200 |
On 05/31/2013 11:52 AM, Peter Rosin wrote:
> On 2013-05-31 11:36, Stefano Lattarini wrote:
>>> With that info (and with the help of the docs for the --langmap option), I
>>> can make the test PASS *for this etags* with the below patch.
>>>
>>> I also question if it's wise to 'cat TAGS' in the test, as I have
>>> non-printable characters the tags files.
>>>
>> Log files generated by the automake testsuite harness should be able to
>> contain
>> binary output without confusing any of the other automake-generated recipes.
>> That is considered a feature, and is also tested in the Automake testsuite
>> somewhere. Are you having concrete problem with this? If yes, that's a bug
>> we might want to address.
>
> No, no concrete problem here, but it makes it harder to exchange the log
> files, especially since people might assume they are regular text files.
> They sure look texty on a cursory glance.
>
Let's cross that bridge when we come to it then (i.e., a real problem arises).
Of course, feel free to go ahead if you want to write a patch to preventively
addresses this and similar potential issues (I think is should be easily
doable using perl). I won't do it myself, but I'll certainly ACK a patch
from you.
>>>
>>> diff --git a/t/tags-pr12372.sh b/t/tags-pr12372.sh
>>> index 4eeb9be..14b500e 100644
>>> --- a/t/tags-pr12372.sh
>>> +++ b/t/tags-pr12372.sh
>>> @@ -63,7 +63,7 @@ $AUTOMAKE
>>>
>>> ./configure
>>>
>>> -$MAKE
>>> +$MAKE ETAGSFLAGS="--langmap=c:+.pc"
>>>
>> This will break with my etags, though.
>
> Of course, that is why I emphasized *with this etags* above. I never
> expected this patch to fly, it was a throwaway thing (I didn't even
> commit it locally, and I didn't send it to automake-patches). I
> considered it only as input to whomever would write a proper patch.
>
>> $ etags --version
>> etags (GNU Emacs 23.4)
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> This program is distributed under the terms in ETAGS.README
>>
>> Maybe you should make your change condition to whether etags is
>> "Exuberant Ctags"?
>
> Or, even better, check if etags swallows "--langmap=c:.pc", which
> seems more robust than relying on names and versions of tools.
>
> I'm not going to write the patch this week though, and possibly
> not in the near future as I have other things ($$$) to do as well...
>
Not to worry, the bug remains open, I will get to it eventually
(maybe soon).
Thanks,
Stefano