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

[Arnaud Fontaine]

Hi,

Gaetan Nadon <memsize at videotron.ca> writes:

> 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).
> [...]
>
> 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.


'PKG_CHECK_MODULES([XCB], [xcb >= 1.4] [xcb-proto >= 1.6])' is wrong
IMO. What we want to test is which version of xcb-proto was used to
build libxcb, there is no need to check whether xcb-proto module is
available at the end because xcb-proto only provides XML protocol
description and tools used to generate the source code.

Moreover, vendors may want to provide XML and these tools as a separate
package (for example Debian does with xcb-proto package), so this change
would require to add an useless dependencies against xcb-proto in util
library package.

>     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.

While I think it's a good idea to move all relevant macros to
xorg-macros, I don't really see a real benefit in getting rid of
submodules, especially considering that these libraries all call/use the
same macros and we would have copy/paste in all the modules... But
that's just my opinion ;-).

Cheers,
-- 
Arnaud Fontaine