<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Thu, 2010-11-25 at 21:59 -0500, zt.tmzt@gmail.com wrote: <BLOCKQUOTE TYPE=CITE> <PRE> > 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. </PRE> </BLOCKQUOTE> What you need is server + dependencies? I recall a number of posts on the list<BR> from developers who do the same. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> Essentially, variables recognized by a module: <BLOCKQUOTE> <PRE> 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 </PRE> </BLOCKQUOTE> should be transmitted from build.sh to each module invocation (as you did in your patch).<BR> I can't see anything wrong in doing that. This could be extended to configure options<BR> as well. One might use --bindir=/some/place/else on all modules. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> I forgot about that. If we were to supply a file containing a list of<BR> server + dependencies modules, would that be more useful than the "lib only" option? <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> Ok. <BLOCKQUOTE TYPE=CITE> <PRE> 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? </PRE> </BLOCKQUOTE> I am not following, probably script internal details which I'll leave to Trevor. <BLOCKQUOTE TYPE=CITE> <PRE> > > Reference: > <A HREF="http://wiki.x.org/wiki/ModularDevelopersGuide#BestPractices">http://wiki.x.org/wiki/ModularDevelopersGuide#BestPractices</A> > > 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 <<A HREF="mailto:zt.tmzt@gmail.com">zt.tmzt@gmail.com</A>> tmzt on freenode </PRE> </BLOCKQUOTE> </BODY> </HTML>