emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: etags name collision.


From: Ergus
Subject: Re: [PATCH] Re: etags name collision.
Date: Tue, 12 Apr 2022 13:13:02 +0200

On Tue, Apr 12, 2022 at 07:03:23AM +0200, Ulrich Mueller wrote:
On Tue, 12 Apr 2022, Eli Zaretskii wrote:

Date: Mon, 11 Apr 2022 21:53:50 +0200
From: Ergus <spacibba@aol.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org

>I still think that any test for an installed binary is a bad idea, from
>a distro point of view. Note that distros typically build packages in an
>environment that is different from the one of the final target system.
>
Here I agree

How else to test whether this is needed?  I'm okay with having
"--without-ctags" with no test, but then the default will have to be
to install our ctags.

That sounds good.

With the test, we could refrain from installing it if the test says
so.

But then the test should be more specific, and check if there would be a
file collision at the actual target location (with the name modified by
--program-transform-name, if applicable). If there's no collision (e.g.
Emacs ctags has a different name) then Emacs should install it.

If we don't do that with mailutils why should we do it with ctags... It
will be more complex and error prone. I would be even simpler and just
add the option --without-ctags to not build our ctags on demand
unconditionally, keeping things as they are now by default.

as a plus we could make: --with-ctags=no, to not build; and we could
allow to do things like: --with-ctags=ctags.emacs to explicitly create
it as ctags.emacs... But I am sure such method will break some standard
or development agreement.


I'm also okay with leaving things as they are now, obviously, if this
change brings more problems than it solves.  I don't consider the
current situation bad enough to necessitate any changes.

Things are like this since more than a decade, and obviously distros can
cope with the status quo.

1) Then exuberant ctags was not so popular
2) The popular languages then were very different than today (even C++
was very different then)
3) There was not universal ctags which supports all of them and our formats.


reply via email to

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