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

[Peter Hutterer]

On Thu, Nov 25, 2010 at 09:59:38PM -0500, zt.tmzt at gmail.com wrote:
> > 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.

each module has a number of configure flags, so there is no simple list for
"build all server prereqs". especially in your case, which is rather far
from the default.
e.g.: if you're only building the Xorg DDX, then you don't need libX11. If
you build Xdmx, you need libX11 but (until recently) a configure flag
allowed you to then add/remove the dependency for libxcb. which in turn
requires xcb-proto and pthread-stubs, etc, etc.

I think that having users keep their own module lists if they don't
want to build everything is the only maintainable approach in the long run.

Cheers,
  Peter

> 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
> >
> >
>