GNU bug report logs - #14517
t/tags-pr12372.sh assumes that etags generates tags for all files

Previous Next

Package: automake;

Reported by: Peter Rosin <peda <at> lysator.liu.se>

Date: Fri, 31 May 2013 09:18:02 UTC

Severity: minor

Tags: patch

Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14517 in the body.
You can then email your comments to 14517 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Fri, 31 May 2013 09:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Rosin <peda <at> lysator.liu.se>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Fri, 31 May 2013 09:18:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: bug-automake <at> gnu.org
Subject: t/tags-pr12372.sh assumes that etags generates tags for all files
Date: Fri, 31 May 2013 11:15:42 +0200
Hi!

I recently installed etags on Cygwin.

$ etags --version
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Dec 11 2009, 11:42:40
  Addresses: <dhiebert <at> users.sourceforge.net>, http://ctags.sourceforge.net
  Optional compiled features: +wildcards, +regex, +internal-sort

This caused t/tags-pr12372.sh (v1.13.2-63-gb4bfacb, i.e. not the very
latest, but close enough) to go from SKIP to FAIL.

The reason for the FAIL is that this etags program will not by default
generate any tags for file extensions it does not recognize.

Quoting from the manual:


SOURCE FILES
       Unless  the  --language-force option is specified, the language of each
       source file is automatically selected based  upon  a  mapping  of  file
       names  to  languages.  The  mappings in effect for each language may be
       display using the --list-maps option  and  may  be  changed  using  the
       --langmap option.  On platforms which support it, if the name of a file
       is not mapped to a language and the file is executable, the first  line
       of the file is checked to see if the file is a "#!" script for a recog‐
       nized language.


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.

Cheers,
Peter


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"
 cat TAGS
 cat sub/TAGS
 $FGREP foo-main.pc TAGS




Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Fri, 31 May 2013 09:39:01 GMT) Full text and rfc822 format available.

Message #8 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 14517 <at> debbugs.gnu.org
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Fri, 31 May 2013 11:36:38 +0200
severity 14517 minor
stop

Hi Peter, thanks for the report.

On 05/31/2013 11:15 AM, Peter Rosin wrote:
> Hi!
> 
> I recently installed etags on Cygwin.
> 
> $ etags --version
> Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
>   Compiled: Dec 11 2009, 11:42:40
>   Addresses: <dhiebert <at> users.sourceforge.net>, http://ctags.sourceforge.net
>   Optional compiled features: +wildcards, +regex, +internal-sort
> 
> This caused t/tags-pr12372.sh (v1.13.2-63-gb4bfacb, i.e. not the very
> latest, but close enough) to go from SKIP to FAIL.
> 
> The reason for the FAIL is that this etags program will not by default
> generate any tags for file extensions it does not recognize.
> 
> Quoting from the manual:
> 
> 
> SOURCE FILES
>        Unless  the  --language-force option is specified, the language of each
>        source file is automatically selected based  upon  a  mapping  of  file
>        names  to  languages.  The  mappings in effect for each language may be
>        display using the --list-maps option  and  may  be  changed  using  the
>        --langmap option.  On platforms which support it, if the name of a file
>        is not mapped to a language and the file is executable, the first  line
>        of the file is checked to see if the file is a "#!" script for a recog‐
>        nized language.
> 
> 
> 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.

> Cheers,
> Peter
> 
> 
> 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.

  $ 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"?

>  cat TAGS
>  cat sub/TAGS
>  $FGREP foo-main.pc TAGS
> 
> 

Thanks,
  Stefano




Severity set to 'minor' from 'normal' Request was from Stefano Lattarini <stefano.lattarini <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 31 May 2013 09:39:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Fri, 31 May 2013 09:55:01 GMT) Full text and rfc822 format available.

Message #13 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 14517 <at> debbugs.gnu.org
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Fri, 31 May 2013 11:52:29 +0200
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.

>>
>> 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...

Cheers,
Peter





Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Fri, 31 May 2013 10:01:01 GMT) Full text and rfc822 format available.

Message #16 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 14517 <at> debbugs.gnu.org
Subject: Re: 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




Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Fri, 31 May 2013 10:04:02 GMT) Full text and rfc822 format available.

Message #19 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 14517 <at> debbugs.gnu.org
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Fri, 31 May 2013 12:02:05 +0200
On 2013-05-31 11:58, Stefano Lattarini wrote:
> On 05/31/2013 11:52 AM, Peter Rosin wrote:
>> 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).

Yup, I'm happy to test anything you come up with (within reason :-).

Cheers,
Peter





Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Mon, 03 Jun 2013 09:50:01 GMT) Full text and rfc822 format available.

Message #22 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 14517 <at> debbugs.gnu.org
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Mon, 03 Jun 2013 11:47:23 +0200
tags 14517 + patch
thanks

On 05/31/2013 12:02 PM, Peter Rosin wrote:
> On 2013-05-31 11:58, Stefano Lattarini wrote:
>> On 05/31/2013 11:52 AM, Peter Rosin wrote:
>>> 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).
> 
> Yup, I'm happy to test anything you come up with (within reason :-).
> 
Here it is.  Does it work for you?

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 9137db89c88d5fceed1c80beeb2969d36a9e72c9 Mon Sep 17 00:00:00 2001
Message-Id: <9137db89c88d5fceed1c80beeb2969d36a9e72c9.1370252733.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Mon, 3 Jun 2013 11:45:29 +0200
Subject: [PATCH] tests: fix spurious failure when 'etags' program is Exuberant Ctags

Fixes automake bug#14517.

* t/tags-pr12372.sh: If the 'etags' program in use supports the
'--langmap' option, use it.  That is required to avoid spurious
failures with Exuberant Ctags (at least version 5.8), which by
default do not generate any tags for file extensions it doesn't
recognize.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 t/tags-pr12372.sh | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/t/tags-pr12372.sh b/t/tags-pr12372.sh
index 4eeb9be..657be60 100644
--- a/t/tags-pr12372.sh
+++ b/t/tags-pr12372.sh
@@ -63,7 +63,17 @@ $AUTOMAKE

 ./configure

-$MAKE
+# Exuberant Ctags (at least version 5.8) do not generate any tags
+# for file extensions it doesn't recognize.  This can be fixed by
+# using the '--langmap' option.  But we must be careful, because
+# etags from Emacs (at least version 23.4) doesn't recognize that
+# option.
+if etags --help | grep '.*--langmap'; then
+  run_make ETAGSFLAGS="--langmap=c:+.pc"
+else
+  $MAKE
+fi
+
 cat TAGS
 cat sub/TAGS
 $FGREP foo-main.pc TAGS
-- 
1.8.3.rc3.8.g5e49f30







Added tag(s) patch. Request was from Stefano Lattarini <stefano.lattarini <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 03 Jun 2013 09:50:01 GMT) Full text and rfc822 format available.

Reply sent to Stefano Lattarini <stefano.lattarini <at> gmail.com>:
You have taken responsibility. (Mon, 03 Jun 2013 13:24:02 GMT) Full text and rfc822 format available.

Notification sent to Peter Rosin <peda <at> lysator.liu.se>:
bug acknowledged by developer. (Mon, 03 Jun 2013 13:24:03 GMT) Full text and rfc822 format available.

Message #29 received at 14517-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 14517-done <at> debbugs.gnu.org
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Mon, 03 Jun 2013 15:21:04 +0200
On 06/03/2013 11:47 AM, Stefano Lattarini wrote:
>
> Peter Rosin wrote:
>>
>> Yup, I'm happy to test anything you come up with (within reason :-).
>>
> Here it is.  Does it work for you?
> 
> PATCH] tests: fix spurious failure when 'etags' program is Exuberant Ctags
> 
> Fixes automake bug#14517.
> 
> * t/tags-pr12372.sh: If the 'etags' program in use supports the
> '--langmap' option, use it.  That is required to avoid spurious
> failures with Exuberant Ctags (at least version 5.8), which by
> default do not generate any tags for file extensions it doesn't
> recognize.
> 
I've tried the patch with etags from both Exuberant Ctags and from
Emacs, and everything works correctly.  I'm thus closing this report.
Peter, please holler if the problems somehow still persists for you,
since I'm planning to release Automake 1.13.3 this evening or
tomorrow morning.

Thanks, and best regards,
  Stefano




Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Mon, 03 Jun 2013 13:47:01 GMT) Full text and rfc822 format available.

Message #32 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: 14517 <at> debbugs.gnu.org, stefano.lattarini <at> gmail.com
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Mon, 03 Jun 2013 15:44:18 +0200
On 2013-06-03 15:21, Stefano Lattarini wrote:
> On 06/03/2013 11:47 AM, Stefano Lattarini wrote:
>>
>> Peter Rosin wrote:
>>>
>>> Yup, I'm happy to test anything you come up with (within reason :-).
>>>
>> Here it is.  Does it work for you?
>>
>> PATCH] tests: fix spurious failure when 'etags' program is Exuberant Ctags
>>
>> Fixes automake bug#14517.
>>
>> * t/tags-pr12372.sh: If the 'etags' program in use supports the
>> '--langmap' option, use it.  That is required to avoid spurious
>> failures with Exuberant Ctags (at least version 5.8), which by
>> default do not generate any tags for file extensions it doesn't
>> recognize.
>>
> I've tried the patch with etags from both Exuberant Ctags and from
> Emacs, and everything works correctly.  I'm thus closing this report.
> Peter, please holler if the problems somehow still persists for you,
> since I'm planning to release Automake 1.13.3 this evening or
> tomorrow morning.

Hi Stefano!

I was right in the middle of something, but since you're on a tight
schedule, I took the time to check and it indeed fixes the problem
here. Thanks!

There is one little nitpick in the comment if you care:

+# Exuberant Ctags (at least version 5.8) do not generate any tags
                                         ^^^^
s/ do / does /

Cheers,
Peter





Information forwarded to bug-automake <at> gnu.org:
bug#14517; Package automake. (Mon, 03 Jun 2013 14:25:02 GMT) Full text and rfc822 format available.

Message #35 received at 14517 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 14517 <at> debbugs.gnu.org
Subject: Re: bug#14517: t/tags-pr12372.sh assumes that etags generates tags
	for all files
Date: Mon, 03 Jun 2013 16:22:05 +0200
On 06/03/2013 03:44 PM, Peter Rosin wrote:
> On 2013-06-03 15:21, Stefano Lattarini wrote:
>> On 06/03/2013 11:47 AM, Stefano Lattarini wrote:
>>>
>>> Peter Rosin wrote:
>>>>
>>>> Yup, I'm happy to test anything you come up with (within reason :-).
>>>>
>>> Here it is.  Does it work for you?
>>>
>>> PATCH] tests: fix spurious failure when 'etags' program is Exuberant Ctags
>>>
>>> Fixes automake bug#14517.
>>>
>>> * t/tags-pr12372.sh: If the 'etags' program in use supports the
>>> '--langmap' option, use it.  That is required to avoid spurious
>>> failures with Exuberant Ctags (at least version 5.8), which by
>>> default do not generate any tags for file extensions it doesn't
>>> recognize.
>>>
>> I've tried the patch with etags from both Exuberant Ctags and from
>> Emacs, and everything works correctly.  I'm thus closing this report.
>> Peter, please holler if the problems somehow still persists for you,
>> since I'm planning to release Automake 1.13.3 this evening or
>> tomorrow morning.
> 
> Hi Stefano!
> 
> I was right in the middle of something, but since you're on a tight
> schedule, I took the time to check and it indeed fixes the problem
> here. Thanks!
>
Thank you, this is really appreciated.

> There is one little nitpick in the comment if you care:
> 
> +# Exuberant Ctags (at least version 5.8) do not generate any tags
>                                          ^^^^
> s/ do / does /
>
Thanks, since I've already merged to maint I'll fix that up with a
later commit in your name.

Regards,
  Stefano




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 02 Jul 2013 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 41 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.