<!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 Wed, 2010-10-06 at 16:16 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>I agree... but to be honest I think the more pertinent question is:</TT> <TT>why would a user be trying to build unknown sub-projects? Shouldn't</TT> <TT>all the projects be known to the build.sh script? Should the script</TT> <TT>even support unknown projects? If a new project is being added to the</TT> <TT>X.Org family, shouldn't it be patched into the build script the way</TT> <TT>the others are already?</TT> <TT>> If it is not doable, we should have a way for users to quickly find out it's</TT> <TT>> the way it works so</TT> <TT>> he does not waste time debugging.</TT> <TT>I'll think about ways to build unknown projects in whatever order</TT> <TT>they're specified, but I really think projects that aren't known to</TT> <TT>the script shouldn't be supported at all.</TT> <TT>Let's say you're working on a new project to be added:</TT> <TT>"xf86-video-gaetan". I would hope that as part of your development you</TT> <TT>would determine where in the sub-project list it should be built, add</TT> <TT>it to the build.sh script, then submit it when you send in the patches</TT> <TT>for the rest of your work. In other words, if you're working on</TT> <TT>something locally that isn't yet available publicly, just patch your</TT> <TT>build.sh to support your new project, then send it in when the rest of</TT> <TT>your work gets accepted.</TT> <TT>I was under the impression one of the most important things the</TT> <TT>build.sh script provides for the user is the ability to build all the</TT> <TT>sub-projects of X.Org in the correct order. So in that case no matter</TT> <TT>how the user supplies the list of projects they want built, the script</TT> <TT>should build them in the order it knows will work correctly. I think</TT> <TT>that's important to retain; more important than supporting</TT> <TT>sub-projects which aren't known to the script.</TT> </BLOCKQUOTE> Exactly how I used to see things. But Xorg does not have finite boundaries. The list of modules you see in build.sh has been crafted over several years, adding and removing some around the time of a release. It is based on usage and if there is a maintainer. Some modules gets dropped-off the list because there is no maintainer and the module ceases to function or build. Some modules make a come back after a few years. Here is a concrete example of a module which is included in my distro, has been and will be in use for quite some time: xf86-input-wacom a driver for Wacom tablets. This is the module description, which summarizes it all: <BLOCKQUOTE> <PRE> Note that it is not a part of the X.Org distribution since X11R6: this driver is from the linuxwacom project. See http://linuxwacom.sf.net for details. </PRE> </BLOCKQUOTE> The radeonhd driver is in build.sh but has not yet been include in an Xorg release. The mesa, xcb, pixman and xkeyboard-config are dependencies of xorg, but are separate projects. They are included in build.sh to make it easy to have a complete build. The build.sh script does not reflect the scope of the X.Org Project and does not reflect the content of the current release either. Even the term "release" is too strict, we use "katamari". Back to the feature in question. Assuming what I said makes sense and there is a reasonable use for a custom list, it makes sense that I would add a driver alongside the other drivers and expect it to be build where it is placed in the list. This is not a critical feature, should the implementation effort be unreasonable, I can certainly live with the way it is today. To answer your question in the next post, a user supplied module name that is unknown to build.sh is dealt with on a best effort basis. If there is a typo, it fails to build (or clone). It will be easier to find out if it is processed in list order. The hard-coded module list in build.sh is probably why it is not as popular as it could be. Nobody works on 240 modules at a time. Many don't ever build the apps, for example. About half of them are deprecated and not included in a release. Many are only interested in the server (and it's dependencies), while otehrs may be interested in a full release as customized on their distros. I could be wrong, but I thought that having a custom list would go a long way in making build.sh more useful. That's why I still don't think that sorting a list of modules to build them in order in terribly useful. If this gets in the way of processing modules in the order supplied by the user, I would drop this sorting feature. Gaetan </BODY> </HTML>