Hi Alan, Thanks for the review.
(Please note that I'm purposefully being overly descriptive to help others on the list who might be new to the build.sh script) On Wed, Jan 18, 2012 at 4:09 PM, Alan Coopersmith <[email protected]> wrote: > However, I wasn't quite clear on how to use it - perhaps because > I've failed to pay attention long enough that I didn't remember > what "the --modfile file" referred to (nor have I had time to > look into this patch really, given other priorities recently > eating most of my time). By default build.sh will run through its internal list of all the modules of which it is aware and build all of them in the correct dependency order. Currently that list contains 246 modules on a Linux x86-ish machine. If you only want to build one specific module you can specify it with the "-o" option. But if you want to build a random subset of all the modules (which we assume is a common enough occurrence) it's best to provide a "--modfile <modfile>" option. Currently <modfile> is a plain text file which contains a list of each module you want built, one per line. At the time I was implementing the --modfile option we had discussed whether or not build.sh should be smart enough to sort the items in <modfile> itself based on its internal notion of the correct dependency order, but it was decided that if a user were using the --modfile option they would be confused if build.sh built the modules in an order different than the order specified in the <modfile>. Therefore build.sh builds the modules specified in <modfile> in the given order. To help a user create a <modfile> build.sh provides an "-L" option; if you run "build.sh -L" it will print an in-build-dependency-order list of all the modules of which it is aware (based on the machine's architecture). This output can be a good place to start for creating a custom <modfile>. With this patch I'm proposing an extension to the --modfile mechanism such that each line of the file still lists each of the modules you want built, but any remaining text on a given line (after a space) lists the options you would like passed to that module's configuration. So whereas previously my <mofile> looked like this: ... lib/libXxf86vm lib/libpciaccess pixman/ mesa/drm mesa/mesa data/bitmaps app/appres ... It now looks like this: ... lib/libXxf86vm lib/libpciaccess pixman/ mesa/drm --enable-nouveau-experimental-api mesa/mesa data/bitmaps app/appres ... I'm curious to know what you are using as your custom build infrastructure (if you are at liberty to say). Best regards, Trevor _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
