<!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 Fri, 2010-09-24 at 11:23 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>I understand that people want to create their own list(s), but my</TT> <TT>understanding is that whatever the user selects must be built in a</TT> <TT>specific order, otherwise their build will not succeed.</TT> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <TT> I thought the</TT> <TT>list returned by "build.sh -L" was a list of all possible modules xorg</TT> <TT>has to offer, listed in the order they must be built in order to have</TT> <TT>a successful build.</TT> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <TT> So my future patch to allow the user to specify an</TT> <TT>arbitrary list has logic to compare the user-supplied list to the</TT> <TT>"build.sh -L" list so that it can build the arbitrary list in the</TT> <TT>correct order.</TT> </BLOCKQUOTE> 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) <BLOCKQUOTE TYPE=CITE> <TT>So I was wondering if having an in-order list of all possible xorg</TT> <TT>modules (which is what I assumed "build.sh -L" was providing) might be</TT> <TT>of some use to tools outside build.sh.</TT> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <TT>> I'll have a look at your patch later today.</TT> <TT>The most recent patch I provided is the patch to allow a user to</TT> <TT>perform arbitrary git or make commands over the components they're</TT> <TT>processing. I was hoping that patch would go through first, then a</TT> <TT>cleanup for "no-quit", then the "arbitrary list" patch. I was then</TT> <TT>hoping further cleanups and features would also be considered.</TT> </BLOCKQUOTE> Sounds like a plan. <BLOCKQUOTE TYPE=CITE> <TT>As we've already seen, a patch I provided a couple days ago has</TT> <TT>already needed to be rebased. Had I provided all the patches at once</TT> <TT>it just would have meant more work. I'd also like to see a cleanup go</TT> <TT>in before the "arbitrary list" patch since it would reduce the size of</TT> <TT>any future work/patches.</TT> </BLOCKQUOTE> 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". </BODY> </HTML>