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

[Gaetan Nadon]

On Thu, 2010-11-25 at 21:59 -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.
> 

What you need is server + dependencies? I recall a number of posts on
the list
from developers who do the same.

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

Essentially, variables recognized by a module:

        Some influential environment variables:
          CC          C compiler command
          CFLAGS      C compiler flags
          LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
                      nonstandard directory <lib dir>
          LIBS        libraries to pass to the linker, e.g. -l<library>
          CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include dir> if
                      you have headers in a nonstandard directory <include dir>
          CPP         C preprocessor
          PKG_CONFIG  path to pkg-config utility

should be transmitted from build.sh to each module invocation (as you
did in your patch).
I can't see anything wrong in doing that. This could be extended to
configure options
as well. One might use --bindir=/some/place/else on all modules.

> 
> 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 forgot about that. If we were to supply a file containing a list of
server + dependencies modules, would that be more useful than the "lib
only" option?

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

Ok.

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

I am not following, probably script internal details which I'll leave to
Trevor.

> 
> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101125/d658006d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101125/d658006d/attachment.pgp>