GNU bug report logs - #76322
Make ctags a thin wrapper around etags

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76322 <at> debbugs.gnu.org
Subject: Re: bug#76322: Make ctags a thin wrapper around etags
Date: Sun, 09 Mar 2025 14:15:51 +0200

> Date: Sun, 9 Mar 2025 00:13:51 -0800
> Cc: 76322 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> > Thanks.  This mostly worked, but I needed a few minor changes (below).
> > We should use _spawnvp, not _execvp, since the latter doesn't return,
> > so we cannot return the exit status of etags to the caller.  More
> > importantly, the counting of bytes to allocate missed the PROGRAM part
> > of --ctags=PROGRAM, so ctags would crash in weird ways.  Finally, I
> > need to include stdio.h to get the declaration of perror.  Here's the
> > patch:
> 
> Thanks, I incorporated all that into the proposed patch. A couple of 
> things, though. First, when _spawnvp returns -1 I assume ctags should 
> call perror and exit with status 127 rather than simply try to exit with 
> status -1. Second and more important, my earlier proposal violated the 
> GNU Coding Standards because its behavior depended on its name.[1]
> 
> Fixing the second problem simplified the C and shell code a bit. Revised 
> patch attached.

Thanks, but this doesn't quite work.  The reason is here:

> +  static char const etags_program[] = ETAGS_PROGRAM;

ETAGS_PROGRAM is computed by lib-src/Makefile, which sets it to the
absolute file name of etags in the installation tree.  So if the etags
there doesn't exist (e.g., Emacs was not yet installed), or is not the
new etags which understands the --ctags= option, ctags will fail.  So
I cannot even run the etags test suite after building the patched
tree, because all ctags tests failed.

Why did you drop the previous approach, which just replaced "ctags"
with "etags" in the original argv[0]?  That did work, was reliable,
and allowed to move the installed programs to any other directory
(something that happens a lot on Windows).  It also made sure the pair
of programs came from the same Emacs version, which is also important.
Was there any problem with that approach that required you to abandon
it?

Thanks.

Previous Next

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