[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