[Xcb] Splitting up xcb-util repository
Arnaud Fontaine
arnaud at andesi.org
Tue Aug 24 13:46:09 PDT 2010
Hi,
Sorry for the late reply, I was busy with IRL issues ;).
> We are talking 2.62 here, which is just 2 years behind (2008).
> It's not available (as a distro installable package) in Hardy LTS
> for example and probably not on Solaris.
And probably other distributions we are not aware of. 2 years is
probably not enough and I guess a lot of people would complain if we
require such a "recent" version of autoconf.
> Suggestion: you can use this macro in xcb, forcing the issue of
> upgrading. Anyone who wants to build xcb has to upgrade. If we
> put it in util-macros, everyone need to upgrade their computer
> overnight to build any of the 240 packages. After a while, when
> people have upgraded, we can promote the macro to util-macros
> without compatibility issues for xcb.
> I am far from being against upgrading, in this case the code would
> be ahead of the installed toolchain. We would be ok to use
> automake 1.10 however.
Would AC_PATH_PROGS_FEATURE_CHECK be useful for another macros of
util-macros? If not, I agree with you about adding the macro to xcb
(through the m4-common repository already used for macros common to
xcb-util libraries) rather than util-macros. In case
AC_PATH_PROGS_FEATURE_CHECK would be useful for other macros in
util-macros, why not just have something like:
m4_ifndef([AC_PATH_PROGS_FEATURE_CHECK], [
AC_DEFUN([AC_PATH_PROGS_FEATURE_CHECK], [COPY_OF_MACROS_FROM_AUTOCONF])
])
Then, as soon as Autoconf 2.62 becomes the minimum version, we can just
get rid of that easily. What do you think?
Cheers,
--
Arnaud Fontaine (arnau)
More information about the Xcb
mailing list