Hi,
On Wed, Apr 14, 2010 at 07:26:26PM +0300, Tiago Vignatti wrote:
> 1. one single option disabling a very basic set and to be used for all sort of
> embedded; would be --enable-xorg-minimal containing _part_ of modules and
> extensions options but not for instance --disable-glx, cause some devices
> might want to use it.
>
> 2. Try to separate in smaller groups like: --disable-hw-access (for vgahw,
> vbe, int10, pci), --disable-remote-access (xdmcp, xdm-auth, ipv6,
> tcp-transport, rpc) and etc.
>
> 3. don't remove any option from there and just clean up configure.ac. Well,
> kernel has already zillion ways to configure it and seems that works nicely.
>
>
> Honestly, it's not so clear to me why people were shouting so loud regarding
> these bunch of --enable-{disable}-$option inclusions. If the purpose is
> testing
> coverage then I'd say to go for 1. If the real problem is the mess in
> configure.ac then 3. looks fine. The second approach is middle term of both.Test coverage was a reasonable amount of it -- we've not had a very good track record of keeping different combinations of options building at all (especially if you throw drivers into the mix). Also, yeah, our configure.ac is about as intractable as it gets right now. --enable-extensions=foo,bar,baz,... and --disable-extensions=foo,bar,baz,... seems OK at first glance, but what happens when you specify --disable-extensions=fixes? Does it know to disable Composite as well? The whole thing gets fairly hairy fairly quickly. Do you have hard numbers on what it's actually saving, particularly as to whether it affects the number of pages that actually get accessed rather than the on-disk size? Cheers, Daniel
pgplqSjzeZTWB.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
