<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
On Tue, 2011-09-20 at 14:53 -0700, Alan Coopersmith wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 09/20/11 04:24, Gaetan Nadon wrote:
> On Mon, 2011-09-19 at 17:17 -0700, Alan Coopersmith wrote:
>> Mostly straightforward addition of new xcb/util-* submodules, but
>> util-common-m4 needs special handling since it doesn't have the
>> usual autoconfery, just needs to be found in the aclocal path when
>> autoconfing the other xcb/util* modules.
>>
> What is the motivation for adding these packages? There are not used for x.org
> release (except common-m4 git submodule). Is there a plan to do so?
I'm not sure we have a plan to rely on them soon, but we want to make sure
they're building and working, as it's my understanding that they are intended
to be supported and included in distros. At least xwininfo has options to
start using some of them, and as more Xorg apps convert to xcb, more may become
required.
</PRE>
</BLOCKQUOTE>
At some point in time, jhbuild should be updated as well.
<BLOCKQUOTE TYPE=CITE>
<PRE>
> The util-common-m4 is a git submodule and gets pulled-in by the hosting module.
> I had updated the script to handle git submodule and it is currently working for
> the xcb util that has been shipped in the last release. The jhbuild system had
> also done so.
>
> If you look in your current build under xdb/util, note the m4 directory. This
> comes from the util-common-m4 git submodule. That's the nice thing, every
> package using this git submodule has a copy of it in its tarball. No issues with
> using a back level version util-common-m4.
>
> At the time of the xcb module split, I updated the Develop Guide:
> <A HREF="http://wiki.x.org/wiki/ModularDevelopersGuide#Workingwithgitsubmodules">http://wiki.x.org/wiki/ModularDevelopersGuide#Workingwithgitsubmodules</A>
Sorry, I completely missed that, just saw that the other submodules didn't seem
to build.
</PRE>
</BLOCKQUOTE>
The git submodules have a public relation problem. Nothing tells you there is one and you get a strange build failure. You don't think of running the 'git submodule' commands.<BR>
I ran util/modular/build.sh --clone -o xcb/util-image with the amended patch and it works fine.
<BLOCKQUOTE TYPE=CITE>
<PRE>
I guess that means we should do similar submodule setups for them, and then this
part of the patch is not useful:
>> @@ -363,6 +363,8 @@ process() {
>> if [ -f $module/$component/autogen.sh ]; then
>> SRCDIR="$module/$component"
>> CONFCMD="autogen.sh"
>> + elif [ X"$component" = Xutil-common-m4 ]&& [ -f
$module/$component/xcb_util_common.m4 ] ; then
>> + SRCDIR="$module/$component"
>> elif [ X"$CLONE" != X ]; then
>> clone $module $component
>> if [ $? -eq 0 ]; then
>> @@ -419,6 +421,15 @@ process() {
>> fi
>> fi
>>
>> + # xcb/util-common-m4 doesn't have configure or Makefile, just macros that
>> + # the other xcb/util* modules need to find in ACLOCAL
>> + if [ X"$component" = Xutil-common-m4 ]; then
>> + echo linking *.m4 into ${ACLOCAL_LOCALDIR}
>> + ln -sf `pwd`/*.m4 ${ACLOCAL_LOCALDIR}
>> + cd $old_pwd
>> + return 0
>> + fi
>> +
>> # Build outside source directory
>> if [ X"$DIR_ARCH" != X ] ; then
>> mkdir -p"$DIR_ARCH"
>> @@ -637,7 +648,12 @@ build_lib() {
>> build lib libXdmcp
>> build xcb pthread-stubs
>> build xcb libxcb
>> + build xcb util-common-m4
but that still leaves:
>> @@ -213,9 +213,9 @@ checkfortars() {
>> module="xcb/libxcb"
>> component="libxcb"
>> ;;
>> -"util")
>> - module="xcb/util"
>> - component="xcb-util"
>> + util*)
>> + module="xcb/$component"
>> + component="xcb-$component"
>> ;;
>> esac
>> ;;
>> @@ -637,7 +648,12 @@ build_lib() {
>> build lib libXdmcp
>> build xcb pthread-stubs
>> build xcb libxcb
>> build xcb util
>> + build xcb util-image
>> + build xcb util-keysyms
>> + build xcb util-renderutil
>> + build xcb util-wm
>> build lib libX11
>> build lib libXext
>> case $HOST_OS in
>
</PRE>
</BLOCKQUOTE>
For the bottom part:<BR>
Reviewed-by: Gaetan Nadon <<A HREF="mailto:memsize@videotron.ca">memsize@videotron.ca</A>><BR>
<BR>
</BODY>
</HTML>