[Xcb] Splitting up xcb-util repository
arnaud at andesi.org
Wed Aug 11 05:02:42 PDT 2010
>> I guess you mean XORG_STRICT_OPTION? If X.Org can get away with
>> requiring C99 compilers, then I'm certainly happy to go along.
Yes, I meant XORG_STRICT_OPTION, sorry ;).
>> Except that libX11, for example, calls XORG_DEFAULT_OPTIONS which
>> includes XORG_STRICT_OPTION, but then later it calls AC_PROG_CC,
>> and from the comments in xorg-macros.m4 I guess that means libX11
>> is only asking for C89? Perhaps the XCB utility libraries should
>> do the same unless they depend on C99 features.
I also noticed this comment but I think it wouldn't be a problem to use
C99 everywhere. However, I might be wrong from a portability point of
view, in such case, we can just revert the modification and only require
C99 when relevant.
> The packages (about 240 of them) used the AC_PROG_CC macro to
> setup the compiler environment (in config.log look for
> CC='gcc'). Later the XORG_STRICT_OPTION was added and called from
> XORG_DEFAULT_OPTIONS, but most of the time it gets overridden by
> AC_PROG_CC. If not, you see CC='gcc -std=gnu99' in the log.
> If you grep all config.log, about half the packages have one and
> half have the other. Very consistent :-) I am in the process of
> removing AC_PROG_CC. I don't recall hearing about any issues with
Ok, so, all the packages will finally end up being built with
C99. Therefore, I think it's safe to do so in XCB too. Anyone against
> I have to make some assumptions here:
> - the xcb/util repository is moving into five new repositories
> - opportunities for reuse are being investigated
>> > 
> I see a couple of reusable chunks, mainly the version compare and
> setting related xcb path. The rest is miscellaneous and kills
> reusability. I would factor out these two chunks in separate
> macros. Just like C code, it's more reusable if it does only one
> thing and has no side-effects.
> It remains to be seen if either of those are reusable by non-xcb
> packages (libX11?). I cannot answer that.
> There is a dependency on AX_* macros. You cannot rely on this
> macro being present on all platforms, being at the correct version
> or not being hacked. Xorg is a similar position with respect to
> AX_* macros. The only safe way is for any package using it to
> have it's own copy. This means there cannot be a copy in
> util-macros, for example.
I completely agree with you that most of the code of this macro just
kills reusability and unlikely to be used for anything else besides of
XCB util libraries. So, I think it would be better to just have a
separate Git repository (such as util-common-m4) for AX_COMPARE_VERSION
and this macro, which would be imported into the util* repositories as a
>> > 
> This one is reusable. Xorg packages do not check for the presence
> of m4. This is the message I get if it missing:
> autoreconf: running: aclocal -I
> /home/nadon/xorg/src/share/aclocal autom4te: need GNU m4 1.4 or
> later: /usr/bin/m4
In fact, this macro would not be useful when getting the source code
through Git repository, but rather when building the source from a
vendor point of view, where the autoconf/automake files have already
been generated for a given release. In XCB libraries, we sometimes rely
on M4 macros within C files (for Atoms generally).
Thanks to both of you for the quick reply!
Arnaud Fontaine (arnau)
More information about the Xcb