<!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 Tue, 2010-10-05 at 17:35 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>From: Trevor Woerner <<A HREF="mailto:twoerner@gmail.com">twoerner@gmail.com</A>></TT> <TT>New feature.</TT> <TT>Using the new "--modlist <file>" option, the user can specify a file which</TT> <TT>contains a list of the module/component items to process. The file can contain</TT> <TT>blank lines and comment lines which start with a hash mark (#).</TT> <TT>The list can be in any arbitrary order, the script will process them in the</TT> <TT>correct dependency order. The script can't figure out what the dependencies</TT> <TT>are, it expects the list to contain the necessary module/component items.</TT> <TT>The script attempts to process any unknown items at the end of the known list.</TT> </BLOCKQUOTE> Any reasons why this is better for the user? I think 99 out of a 100 users will expect the module to be build in the order specified in the provided list. If it is not doable, we should have a way for users to quickly find out it's the way it works so he does not waste time debugging. <BLOCKQUOTE TYPE=CITE> <TT>Suggested usage:</TT> <TT>    1. run script go generate the list of known items, redirecting to a file</TT> </BLOCKQUOTE>                                    || type? "to" prehaps <BLOCKQUOTE TYPE=CITE> <TT>        $ util/modular/build.sh -L > modulefile</TT> <TT>    2. edit file, commenting or deleting out unnecessary items</TT> <TT>    3. run the build off the list:</TT> <TT>        $ util/modular/build.sh $PREFIX --modfile modulefile ...</TT> </BLOCKQUOTE> This is great stuff. </BODY> </HTML>