|
Description
Gaetan Nadon
2009-09-06 12:14:42 UTC
Created attachment 29273 [details] [review] [PATCH] util/macros:Install ax_define_dir.m4 to replace modules private copy Created attachment 29274 [details] [review] [PATCH] app/xfs:Replace AC_DEFINE_DIR private copy with offical AX_DEFINE_DIR Created attachment 29275 [details] [review] [PATCH] afs/xdm:Replace AC_DEFINE_DIR private copy with offical AX_DEFINE_DIR app/xdm Created attachment 29276 [details] [review] [PATCH] libXt: Replace AC_DEFINE_DIR private copy with official AX_DEFINE_DIR Created attachment 29277 [details] [review] [PATCH] libXpm: Replace AC_DEFINE_DIR private copy with official AX_DEFINE_DIR Created attachment 29278 [details] [review] [PATCH] libX11: Replace AC_DEFINE_DIR private copy with official AX_DEFINE_DIR Created attachment 29280 [details] [review] [PATCH] libpciaccess: Replace AC_DEFINE_DIR private copy with official AX_DEFINE_DIR Created attachment 29281 [details] [review] [PATCH] xserver: Replace AC_DEFINE_DIR private copy with official AX_DEFINE_DIR On Sun, Sep 6, 2009 at 12:14:43 -0700, bugzilla-daemon@freedesktop.org wrote: > All the non-gnu macros have been renamed to respect the AC_ Autoconf namespace. > An alias is provided for backward compatibility. The official copy will now be > installed in share/aclocal and available to all modules. I don't think it's a good idea for Xorg to install a system-wide copy of that macro. (In reply to comment #9) > On Sun, Sep 6, 2009 at 12:14:43 -0700, bugzilla-daemon@freedesktop.org wrote: > > > All the non-gnu macros have been renamed to respect the AC_ Autoconf namespace. > > An alias is provided for backward compatibility. The official copy will now be > > installed in share/aclocal and available to all modules. > > I don't think it's a good idea for Xorg to install a system-wide copy of > that macro. > Hi Julien, Would you care to elaborate on the reasons why you think it is not advisable? I wouldn't want to promote the use of something that isn't recommended. I was acting on the general principle that multiple copies of the same code is rarely desirable. Thanks for taking the time to review this. (In reply to comment #10) > (In reply to comment #9) > > I don't think it's a good idea for Xorg to install a system-wide copy of > > that macro. > > Would you care to elaborate on the reasons why you think it is not advisable? I > wouldn't want to promote the use of something that isn't recommended. I was > acting on the general principle that multiple copies of the same code is rarely > desirable. As much as I hate maintaining multiple copies of the same code, here I agree with Julian - since we're not the upstream maintainers of the AX_DEFINE_DIR macro, we shouldn't be installing a system-wide copy of it, and possibly overwriting/overriding other projects copies. The best solution would be to get AC_DEFINE_DIR into a future autoconf release upstream, so all projects can use the standard/common version, but until then, since it's a single separate file that we just have to refresh every year or two, maintaining per-project copies is not that high of a burden. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > I don't think it's a good idea for Xorg to install a system-wide copy of > > > that macro. > > > > Would you care to elaborate on the reasons why you think it is not advisable? I > > wouldn't want to promote the use of something that isn't recommended. I was > > acting on the general principle that multiple copies of the same code is rarely > > desirable. > > As much as I hate maintaining multiple copies of the same code, here > I agree with Julian - since we're not the upstream maintainers of the > AX_DEFINE_DIR macro, we shouldn't be installing a system-wide copy of > it, and possibly overwriting/overriding other projects copies. The > best solution would be to get AC_DEFINE_DIR into a future autoconf > release upstream, so all projects can use the standard/common version, > but until then, since it's a single separate file that we just have > to refresh every year or two, maintaining per-project copies is not > that high of a burden. > Thanks for this important information. By "other projects" you mean modules that aren't listed in build.sh? In that case there is a danger of collision. I don't think we will see this macro in Autoconf anytime soon as "This solution does not conform to the GNU Coding Standards". Would there be objections if I updated the 7 modules with m4/ax_define_dir.m4 as recommended by Automake? In a separate bug report, I'll cancel this one. There isn't enough evidence that this patch would result in an improvement. Thanks to all reviewers! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.