<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 14-01-06 09:56 AM, Trevor Woerner wrote: </div> <blockquote cite="mid:52CAC41D.1030008@linaro.org" type="cite"> <pre wrap="">A couple days ago I took the list of projects available on fd.o, sorted them by their last change, and noticed there are a number of them missing from the list of modules built by build.sh which appear to still be active projects. For example: mesa/glu, mesa/glut, mesa/demos, mesa/mesa-test, cairo, and a bunch of others (I haven't finished yet). Do you think it would be worth my time to submit a patch to add some of these active projects into the list of modules built by build.sh? </pre> </blockquote> Interesting work... It all depends on how one sees the "mission" of build.sh. My opinion is the script main goal is to build all of the modules needed to have a working copy of X on any platform. There are probably as many "lists" as there are people. The bare minimum set of modules is the one xorg publishes on the web for a release. That's the bare minimum. Add to that legacy apps, drivers and libraries, and you get what you have today. The list has been crafted over time by developers who add/remove modules based on some consensus. It's not an exact science and there is a good error margin. Here is the challenge: if we add a module that is not maintained, it breaks and adds noise on xorg-devel. Same goes for an unstable module during early development, or a module with external dependencies not available on distros. Same for test or demo modules. So, yes, it is best to propose modules on a case by case basis (or an RFC). For the mesa modules you mentioned, I don't think they should be included as they are not directly involved in running X out-of-the-box (I could be wrong on this). Mesa is not an X project, but a dependency, so only the bits needed by X should be included. Looking at all fdo modules may not be the right approach. This would yield too many modules unrelated to xorg. Note the path in the git URL: xorg/... which indicates an xorg module. Dependencies have been added over time such as XCB (which is now part of X) which I documented here: <blockquote><a class="moz-txt-link-freetext" href="http://www.x.org/wiki/Building_the_X_Window_System/#index8h3">http://www.x.org/wiki/Building_the_X_Window_System/#index8h3</a> </blockquote> X has many dependencies and some of them may coincidentally be an fdo module. We would not add it to build.sh if it is commonly available on distros. Again, to reduce the complexity of the build and chances of build breaks. My impression is that build.sh has been fairly well maintained over the years. Recently I revamped the jhbuild xorg.modules list so both are in sync now. All the dependencies are listed, so you can start from scratch specifying just one module and everything needed will be pulled in. </body> </html>