There are multiples copies of the macro AC_DEFINE_DIR in various files. This is not a GNU Autoconf macro as the name would suggest, rather it is a non-gnu.org contribution. The official macro copy is at: http://www.nongnu.org/autoconf-archive/ax_define_dir.html. 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. Patches are provided to remove any module private copy and to change configure.ac to use the new conforming name. The effective code of the macro has not changed, but the name of internal variables have. app/xfs/acinclude.m4 app/xdm/acinclude.m4 lib/libXt/acinclude.m4 lib/libXpm/acinclude.m4 lib/libX11/acinclude.m4 lib/libpciaccess/m4/ac_define_dir.m4 xserver/m4/ac_define_dir.m4
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.