[PATCH modular] Remove "lib only" option from build.sh.

[zt.tmzt at gmail.com]

> Can you give us your opinion on this:
>
> $ util/modular/build.sh -L > modlist.txt
>
> [edit modlist.txt: either delete lines or comment them out with a hash '#']
> $ util/modular/build.sh $PREFIX --modfile modlist.txt

Sure, I've been working more with this is in the last few days.  I
think it would be more useful if there was a quick way to build all
server prereqs, but not drivers and input.  Something like -o lib
would work, except the script doesn't appear to have an internal list
of the components belonging to that set.  jhbuild is more complicated
to setup and not much better for cross compiling.

Another issue I have had is I need to change the C compiler, linker,
CPPFLAGS, CFLAGS, and LDFLAGS, it's not suffiicent to use --host
because the compiler does not comply with GNU naming and is not in the
PATH.  I have done this by adding CPPFLAGS="${CPPFLAGS}" etc. to the
invocation of autogen/configure.

I have a few patches to util/modular which I am putting in a git repo
for the project I am working on, they will be located at
github.com/tmzt/androix-util-modular.

To respond to your original question, that would be fine for somebody
who knows what those modules are and which ones they want, since
configure output and make errors are not sufficient to tell you which
modules you want, this increases the difficulty for someone new to X.
I do a lot of guessing and dpkg -S on my host system to figure out
what package a file belongs to, keep git.freedesktop.org in a browser
window, etc.

The point is xserver needs a certain number of libraries and headers
as prerequesites and the build.sh is the perfect way to bootstrap a
staging tree for a cross compile of X from raw git.

Either a set configuration files, which would have to be maintained,
should be shipped in util/modular or somewhere else, or the script
should be able to parse in some way the module list, determine what
requires what and allow that to be built.

If we keep with the current build_* bash functions, one that
specifically builds X prereqs and optionally builds libX11 etc. would
be useful.

It might be useful to use ${!} to resolve those functions directly,
allowing -o libs to work for instance or -o xserver-prereqs to call
build_libs() and build_xserver_prereqs respectivly.  The could be in
separate file and sourced, possibly one build from the xml file?

>
> Reference:
> http://wiki.x.org/wiki/ModularDevelopersGuide#BestPractices
>
> This recent addition was meant exactly for your scenario. Even better, you
> are not bound by what
> build.sh thinks is the right set of modules for you. There would be nothing
> wrong with keeping
> the -l in parallel with this more flexible feature. We were concerned that
> "too many options"
> would be detrimental. We need user's input on that.
>
>
> On a more general note, this makes it more difficult for someone to
> begin working with the X codebase, as they may be focused on a single
> driver or the xserver/DDXs themselves, building able to install all of
> the prerequesites in one go is of great utility.
>
> That's why we are actively maintaining build.sh
>
> My use case:
>
> I am building X for an arm processor, including all of the libraries
> it requires in a static configuration in a tree under /opt
>
>

--
Timothy Meade <zt.tmzt at gmail.com>
tmzt on freenode