GNU bug report logs -
#14517
t/tags-pr12372.sh assumes that etags generates tags for all files
Previous Next
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.
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):
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):
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):
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):
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):
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):
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):
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):
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):
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.