[PATCH modular] Remove "lib only" option from build.sh.

[Gaetan Nadon]

On Thu, 2010-11-25 at 22:54 -0500, zt.tmzt at gmail.com wrote:

> On Thu, Nov 25, 2010 at 10:11 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Thu, Nov 25, 2010 at 09:59:38PM -0500, zt.tmzt at gmail.com wrote:
> >> > Can you give us your opinion on this:
> >> >
> >> > $ util/modular/build.sh -L > modlist.txt
> >> >
> >> > [edit modlist.txt: either delete lines or comment them out with a hash '#']
> >> > $ util/modular/build.sh $PREFIX --modfile modlist.txt
> >>
> >> Sure, I've been working more with this is in the last few days.  I
> >> think it would be more useful if there was a quick way to build all
> >> server prereqs, but not drivers and input.  Something like -o lib
> >> would work, except the script doesn't appear to have an internal list
> >> of the components belonging to that set.  jhbuild is more complicated
> >> to setup and not much better for cross compiling.
> >
> > each module has a number of configure flags, so there is no simple list for
> > "build all server prereqs". especially in your case, which is rather far
> > from the default.
> > e.g.: if you're only building the Xorg DDX, then you don't need libX11. If
> > you build Xdmx, you need libX11 but (until recently) a configure flag
> > allowed you to then add/remove the dependency for libxcb. which in turn
> > requires xcb-proto and pthread-stubs, etc, etc.
> >

Not to mention mesa. This reminds me there are 85 configure options in
the server!

> 
> You are correct about that, I'm a little absorbed in what I'm doing so
> I'm not quite getting the general case correct here.  I have a script
> in my DDX directory that disables most of that stuff (dmx, etc.).
> 
> Yeah, the XCB option is still in build.sh for some reason, I was
> pretty sure you couldn't build without that.
> 
> So I guess a more general solution, such as the module lists is
> needed, but short of a full build environment.  If this was to be done
> with a configure script in the util/modular directory, which would in
> turn call the xserver's it would know which options to use, for
> instance, it could parse --disable-dmx and not build libX11.  This
> seems like a heavy solution for a small problem though.
> 
> Of course, is xserver configure complained correctly when things were
> missing, it could at least suggest using build.sh -o lib/libX11 or
> dmx-prereqs instead of xf86-prereqs, these would be sourced from a
> scripts.d in the util/modular and ${!} expanded. build_dmx_prereqs,
> build_xf86_prereqs, etc.  All DDXs except for Xephyr, Xnest and Xdmx
> only need the simpler set right, not libX11/libxcb?  Also, those three
> can use system provided libX11 when building natively, and don't need
> libX11 to be in the /opt tree, which is mostly for providing newer
> version of direct server libraries (meaning the ones that have to be
> built from git when testing a prerelease server) as long as /usr/lib
> is in the library path.   So even in the common use case
> 
> ./util/modular/build.sh -o xf86-prereqs would be useful
> 
> 
> > I think that having users keep their own module lists if they don't
> > want to build everything is the only maintainable approach in the long run.
> >
> > Cheers,
> >  Peter
> >
> 

As a starter, can we replace "lib only" option (which seems not to be
useful as is) with a
module list containing xserver + dependencies required for default
configuration (no --enable or --with)?
We will most likely learn a thing or two from that exercise. 


> --
> Timothy Meade <zt.tmzt at gmail.com>
> tmzt on freenode
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101126/bb28945a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101126/bb28945a/attachment.pgp>