[Xcb] [RFC util-wm] An alternate configure.ac

[Gaetan Nadon]

I went through the exercise of writing a configure.ac as it would have
been following the xorg patterns. The pre-reqs are util-macros v1.19
with autoconf 2.62 (yet unreleased).

The discussion would also apply to the other utils repos.

    AC_PREREQ(2.62)
    AC_INIT([xcb-util-wm],[0.4.0],
           
    [https://bugs.freedesktop.org/enter_bug.cgi?product=xcb&component=Utils],
            [xcb-util-wm])
    AC_CONFIG_SRCDIR([Makefile.am])
    AC_CONFIG_HEADERS([config.h])
    AC_CONFIG_MACRO_DIR([m4])

    # Initialize Automake
    AM_INIT_AUTOMAKE([foreign dist-bzip2])
    AM_MAINTAINER_MODE

    # Initialize libtool
    LT_PREREQ([2.2])
    LT_INIT()

    # Require xorg-macros minimum of 1.19 - For XORG_WITH_M4
    m4_ifndef([XORG_MACROS_VERSION],
              [m4_fatal([must install xorg-macros 1.19 or later before
    running autoconf/autogen])])
    XORG_MACROS_VERSION(1.19)
    XORG_DEFAULT_OPTIONS
    XORG_WITH_M4

    # Obtain compiler/linker options from XCB
    PKG_CHECK_MODULES([XCB], [xcb >= 1.4] [xcb-proto >= 1.6])

    AC_CONFIG_FILES([Makefile
        icccm/Makefile
        icccm/xcb-icccm.pc
        ewmh/Makefile
        ewmh/xcb-ewmh.pc
        xcb_util_intro])
    AC_OUTPUT

I see several benefits:

      * Looks trivial like any other configure.ac file given the size of
        the module
      * Virtually no code reuse needed among util repos, given
        util-macros does most of the job
      * No need for the extra complexity of submodules bring (learning
        curve)
      * No macro maintenance in m4
      * Util repos won't have --with-doxygen or --enable-devel-doc if
        they don't need to
      * The standard xorg autogen.sh will do the job (no need to check
        for m4)

_What had to change:_

    The line for xcbincludedir and pkgconfigdir is moved to the
    appropriate makefiles

    The test using pkg-config variable xcbproto_version is replaced with
    the common PKG_CHECK_MODULES test. I checked all versions of xcb and
    xcb-proto. The only scenario where the test might be useful is if
    someone has a 1.4 or 1.5 libxcb that was compiled with 1.5
    xcb-proto, and an xcb-proto 1.6 package is sitting on disk but not
    used to compile libxcb. This scenario (hacked installation) is
    outside the scope of module configuration. I am not saying it has
    not been useful in the past, however.

    As a suggestion, requiring libxcb at 1.6 would remove any doubt
    regarding the level at which xcb-proto was used to compile libxcb.

    Even we keep the more sophisticated xcb-proto level test, the
    proposal still stand.

_Lowest maintenance cost_

    The idea is to lower the cost of maintenance. Having all util repos
    off the common-m4 submodule and fully benefiting from xorg
    infra-structure, there is a benefit for both the maintainer and the
    users.











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140208/b26b3f8e/attachment.html>