[PATCH modular] Implement a classification for scripts using subdirectories

Gaetan Nadon memsize at videotron.ca
Fri Sep 24 10:35:45 PDT 2010


On Fri, 2010-09-24 at 11:23 -0400, Trevor Woerner wrote:

> I understand that people want to create their own list(s), but my
> understanding is that whatever the user selects must be built in a
> specific order, otherwise their build will not succeed.

Correct. You need to know what you are doing when creating a new list.
For example, it could be a list for modules going into 7..6.

>  I thought the
> list returned by "build.sh -L" was a list of all possible modules xorg
> has to offer, listed in the order they must be built in order to have
> a successful build.

99% correct. That list (in build.sh) is result of what the
developers/maintainers
think is useful. It tends to be "more" rather than "less". Last year a
number of protocol
extensions were removed, but the code is still there in the repo and
most likely still in use
on some system.

>  So my future patch to allow the user to specify an
> arbitrary list has logic to compare the user-supplied list to the
> "build.sh -L" list so that it can build the arbitrary list in the
> correct order.

Not at all. The user-supplied list must be in the correct order.
You won't start from scratch here. Take the big list and trim it. (See
below)


> So I was wondering if having an in-order list of all possible xorg
> modules (which is what I assumed "build.sh -L" was providing) might be
> of some use to tools outside build.sh.

Absolutely. As an implementation detail, build.sh may contain a
hard-coded default list
which is exported through the -L option. A user can then customize the
list, say, 
remove a pile of video drivers, and use it back with build.sh as a user
defined list.


> 
> > I'll have a look at your patch later today.
> 
> The most recent patch I provided is the patch to allow a user to
> perform arbitrary git or make commands over the components they're
> processing. I was hoping that patch would go through first, then a
> cleanup for "no-quit", then the "arbitrary list" patch. I was then
> hoping further cleanups and features would also be considered.

Sounds like a plan.

> 
> As we've already seen, a patch I provided a couple days ago has
> already needed to be rebased. Had I provided all the patches at once
> it just would have meant more work. I'd also like to see a cleanup go
> in before the "arbitrary list" patch since it would reduce the size of
> any future work/patches.
> 

It's a pain, isn't? All you need is timing and luck.


With those 2 features, any-list and any-cmd, it will make build.sh a
powerful script,
not to mention other scripts that can written using "any-list".


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100924/efd30fb3/attachment.html>
-------------- 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/20100924/efd30fb3/attachment.pgp>


More information about the xorg-devel mailing list