[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.
- Re: [PATCH] Re: etags name collision., (continued)
- Re: [PATCH] Re: etags name collision., Ulrich Mueller, 2022/04/11
- Re: [PATCH] Re: etags name collision., Ergus, 2022/04/11
- Re: [PATCH] Re: etags name collision., Ulrich Mueller, 2022/04/11
- Re: [PATCH] Re: etags name collision., Ergus, 2022/04/11
- Re: [PATCH] Re: etags name collision., Alfred M. Szmidt, 2022/04/12
- Re: [PATCH] Re: etags name collision., Ulrich Mueller, 2022/04/12
- Re: [PATCH] Re: etags name collision., Ergus, 2022/04/12
- Re: [PATCH] Re: etags name collision., Eli Zaretskii, 2022/04/11
- Re: [PATCH] Re: etags name collision., Po Lu, 2022/04/11
- Re: [PATCH] Re: etags name collision., Ulrich Mueller, 2022/04/12
- Re: [PATCH] Re: etags name collision.,
Ergus <=
- Re: [PATCH] Re: etags name collision., Eli Zaretskii, 2022/04/12
- Re: [PATCH] Re: etags name collision., Eli Zaretskii, 2022/04/12
- Re: [PATCH] Re: etags name collision., Ulrich Mueller, 2022/04/12
- Re: [PATCH] Re: etags name collision., Alfred M. Szmidt, 2022/04/12
- Re: [PATCH] Re: etags name collision., Eli Zaretskii, 2022/04/12
- Re: etags name collision., Stefan Monnier, 2022/04/11
- Re: etags name collision., Eli Zaretskii, 2022/04/11
- Re: etags name collision., Stefan Monnier, 2022/04/11
- Re: etags name collision., Eli Zaretskii, 2022/04/11
- Re: etags name collision., Ulrich Mueller, 2022/04/11