[PATCH modular] Per-component configure options

[Trevor Woerner]

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
<alan.coopersmith at oracle.com> 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