[Xcb] Splitting up xcb-util repository

[Arnaud Fontaine]

Hello,

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

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
that?

    > I have to make some assumptions here:
    > - the xcb/util repository is moving  into five new  repositories
    > - opportunities for reuse are being investigated

Yes.

    >> > [0]
    >> http://cgit.freedesktop.org/~arnau/xorg-util-macros/commit/?id=28c561b3dd5729ffa511cfb3727dfff36477d80a

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

    >> > [1]
    >> http://cgit.freedesktop.org/~arnau/xorg-util-macros/commit/?id=309b691da4d7a3c7e72f1b8a71c1fc18a7039cea
    >> 

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

Cheers,
--
Arnaud Fontaine (arnau)