<!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.26.0">
</HEAD>
<BODY>
On Sun, 2010-05-30 at 15:22 +0800, Matt Dew wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Sat, May 29, 2010 at 11:33 PM, Dirk Wallenstein &lt;<A HREF="mailto:halsmit@t-online.de">halsmit@t-online.de</A>&gt; wrote:
&gt; On Sat, May 29, 2010 at 10:14:21AM -0400, Gaetan Nadon wrote:
&gt;&gt; &nbsp; &nbsp;On Sat, 2010-05-29 at 15:26 +0200, Dirk Wallenstein wrote:
&gt;&gt;
&gt;&gt; On Sat, May 29, 2010 at 08:47:04AM -0400, Gaetan Nadon wrote:
&gt;&gt; &gt;
&gt;&gt; &gt; &nbsp; &nbsp;Geode is hardware specific. It does not build on AMD64, 32 bit only.
&gt;&gt; &gt; &nbsp; &nbsp;Look at util/modular/build.sh to find out about platform restrictions.
&gt;&gt; &gt; &nbsp; &nbsp;I haven't look at jhbuild yet, but I don't think it handles platform
&gt;&gt; &gt; &nbsp; &nbsp;filtering. Does this mean you need to maintain one module set for every
&gt;&gt; &gt; &nbsp; &nbsp;permutation of host/cpu?
&gt;&gt;
&gt;&gt; I think it would be possible to introduce another &lt;autotools&gt; attribute
&gt;&gt; that specifies a filename to execute, and the retval says if it is
&gt;&gt; eligible. Then it might be possible that those modules don't appear in
&gt;&gt; the modules list at all.
&gt;&gt; The autotools attribute would ensure that that file to execute is a
&gt;&gt; tracked file and not one accidentally put there.
&gt;&gt;
&gt;&gt; I think the possibility to enable/disable a module depending on external
&gt;&gt; conditions is generally appealing.
&gt;&gt;
&gt;&gt; That would of course require such a file in the modules that don't build
&gt;&gt; everywhere.
&gt;&gt;
&gt;&gt;
&gt;&gt; &nbsp; &nbsp;I had similar thoughts. A simple text file would do, listing allowed
&gt;&gt; &nbsp; &nbsp;and forbidden host/cpu, as a naive implementation. Perhaps an xml file
&gt;&gt; &nbsp; &nbsp;could reduce coding effort to read it. Using data encapsulation as a
&gt;&gt; &nbsp; &nbsp;guiding principle, a module should know where it can or cannot be
&gt;&gt; &nbsp; &nbsp;built. Currently the information is in the build scripts, so it needs
&gt;&gt; &nbsp; &nbsp;to be duplicated and maintained in multiple build systems.
&gt;
&gt; Sounds good.
&gt;
&gt;&gt; For now I plan to improve the my.modules file, so that it contains
&gt;&gt; corresponding comments, and include the necessary steps in a future
&gt;&gt; setup tutorial.
&gt;
&gt; Ah! Much simpler. The new internal 'init' command that creates a
&gt; repo-group local configuration, can simply fill out the list of modules
&gt; to skip. However, that relies on module-names, it needs to be kept up to
&gt; date, and the user has to drag it along if an alternative configuration
&gt; for the same repo-group is wanted.
&gt;
&gt; That would of course allow to mix in all the libs and drivers into the
&gt; main meta module and let 'init' sort it out. Very good.
&gt;
&gt; Coming soon...
&gt;
&gt; --
&gt; Greetings,
&gt; Dirk
&gt;


Thanks guys,
   I am building on an amd64 box so that explains the geode build.

I did run into a couple others errors:
*** Building xf86-video-impact *** [136/168]
make
make  all-recursive
make[1]: Entering directory `/home/matt/xorg/driver/xf86-video-impact'
Making all in src
make[2]: Entering directory `/home/matt/xorg/driver/xf86-video-impact/src'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I..    -fvisibility=hidden -I/home/matt/xorg-build/include/xorg
-I/home/matt/xorg-build/include/pixman-1   -g -O2 -MT impact_cmap.lo
-MD -MP -MF .deps/impact_cmap.Tpo -c -o impact_cmap.lo impact_cmap.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden
-I/home/matt/xorg-build/include/xorg
-I/home/matt/xorg-build/include/pixman-1 -g -O2 -MT impact_cmap.lo -MD
-MP -MF .deps/impact_cmap.Tpo -c impact_cmap.c  -fPIC -DPIC -o
.libs/impact_cmap.o
In file included from impact_cmap.c:14:
impact.h:19:27: error: xf86Resources.h: No such file or directory
make[2]: *** [impact_cmap.lo] Error 1
make[2]: Leaving directory `/home/matt/xorg/driver/xf86-video-impact/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/matt/xorg/driver/xf86-video-impact'
make: *** [all] Error 2
*** Error during phase build of xf86-video-impact: ########## Error
running make   *** [136/168]

</PRE>
</BLOCKQUOTE>
I cannot comment on this one. It's not part of the xorg release and licensing isn't clear.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
*** Building xf86-video-sunbw2 *** [148/168]
make
make  all-recursive
make[1]: Entering directory `/home/matt/xorg/driver/xf86-video-sunbw2'
Making all in src
make[2]: Entering directory `/home/matt/xorg/driver/xf86-video-sunbw2/src'
  CC     bw2_driver.lo
  bw2_driver.c:31:25: error: xf86Version.h: No such file or directory
  bw2_driver.c:36:20: error: xf1bpp.h: No such file or directory
  bw2_driver.c: In function &#8216;BW2FreeRec&#8217;:
  bw2_driver.c:164: warning: &#8216;Xfree&#8217; is deprecated (declared at
/home/matt/xorg-build/include/xorg/os.h:234)
  bw2_driver.c: In function &#8216;BW2Probe&#8217;:
  bw2_driver.c:234: warning: &#8216;Xfree&#8217; is deprecated (declared at
/home/matt/xorg-build/include/xorg/os.h:234)
  bw2_driver.c:268: warning: &#8216;Xfree&#8217; is deprecated (declared at
/home/matt/xorg-build/include/xorg/os.h:234)
  bw2_driver.c:270: warning: &#8216;Xfree&#8217; is deprecated (declared at
/home/matt/xorg-build/include/xorg/os.h:234)
  make[2]: *** [bw2_driver.lo] Error 1
  make[2]: Leaving directory `/home/matt/xorg/driver/xf86-video-sunbw2/src'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/home/matt/xorg/driver/xf86-video-sunbw2'
  make: *** [all] Error 2
  *** Error during phase build of xf86-video-sunbw2: ########## Error
running make   *** [148/168]

</PRE>
</BLOCKQUOTE>
Deprecated. It has been removed from build.sh not too long ago.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
*** Building xf86-video-xgi *** [162/168]
make
make  all-recursive
make[1]: Entering directory `/home/matt/xorg/driver/xf86-video-xgi'
Making all in src
make[2]: Entering directory `/home/matt/xorg/driver/xf86-video-xgi/src'
  CC     init.lo
In file included from init.h:56,
                 from init.c:67:
vgatypes.h:59:25: error: xf86Version.h: No such file or directory
In file included from init.h:64,
                 from init.c:67:
xgi.h:201:49: error: missing binary operator before token &quot;(&quot;
make[2]: *** [init.lo] Error 1
make[2]: Leaving directory `/home/matt/xorg/driver/xf86-video-xgi/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/matt/xorg/driver/xf86-video-xgi'
make: *** [all] Error 2
*** Error during phase build of xf86-video-xgi: ########## Error running make
*** [162/168]

Since I'm not building/running on a sgi or sun box I'm not sure these
matter.  But I'm reporting them just in case anyway.
</PRE>
</BLOCKQUOTE>
<BR>
The xgi driver got broken recently. It normally builds fine.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Dirk,
 I saw a lot of files in modulesets/ but no my.modules.   Did I
misunderstand the 'my' part?

</PRE>
</BLOCKQUOTE>
<BR>
I think this experience shows how important it is to maintain module sets (add remove). Even more so for those who are new to xorg building. It should just work right out of the box. Except for xgi which got broken recently, all xorg modules build fine. Looking at tinderbox results will help determine if there is a local problem or a problem with the module itself. <A HREF="http://tinderbox.freedesktop.org/">http://tinderbox.freedesktop.org/</A><BR>
<BR>
All,<BR>
I am interested in knowing who writes module sets, what's the criteria for the content and who maintains them. Some are created for tinderbox, but I see only one in util/modular.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
On the plus side,  it did finish building and I was able to run it!
YAY!  The only issue I had was i had to install docbook-xml-dtd
version 4.1.2.  The documentation didn't build with a newer version.

Matt
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>