bug-automake
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]