<!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-09-22 at 17:01 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>I'm concerned about your wording; I hope I haven't come across as</TT> <TT>being opposed to or resisting your ideas on this matter.</TT> </BLOCKQUOTE> Not at all, I just meant I was promoting the idea. Sorry for my poor wording. I did it twice in the same day :-( <BLOCKQUOTE TYPE=CITE> <TT>With regards to the module list, my understanding is that there are two issues:</TT> <TT>1. what is the complete list of possible modules I could build for a</TT> <TT>given platform (e.g. linux-i386)</TT> <TT>2. can the user provide a list to the build script of just the modules</TT> <TT>they want to see built</TT> <TT>"build.sh -L" provides you with the answer to #1.</TT> <TT>I have a patch to provide the functionality of #2, but I'm waiting to</TT> <TT>see what happens to the patch I provided a couple hours ago (perform</TT> <TT>arbitrary git or make commands) and the patch you provided to create</TT> <TT>subdirectories inside util/modular before submitting it. Additionally,</TT> <TT>the functionality of #2 uses the list of #1 to make sure the modules</TT> <TT>are built in the correct order irrespective of the order in which</TT> <TT>they're provided.</TT> <TT>> And if we were to have common module list, they perhaps should be in a</TT> <TT>> separate dir.</TT> <TT>The list of modules (and their order) inside the build.sh script isn't</TT> <TT>entirely static. It changes depending on which platform you are</TT> <TT>building for. So the list wouldn't be a static file, but rather would</TT> <TT>need some logic to be generated correctly. As I've said, "build.sh -L"</TT> <TT>provides you with this list.</TT> </BLOCKQUOTE> I think you have a good understanding of the requirements. You also have noticed there are efforts in different directions (build.sh, jhbuild...), not having any particular solution maintained well enough to work "out of the box" for everyone. You will soon find, if not already done, the story applies to "data", that is the list of modules to build. There isn't a database where you can find a complete list of modules, their versions, in which release they can be found, if they are targeted for "next release, and so on. It's not by negligence, it's the nature of xorg. If there is someone to work on a module, it's alive. I have been maintaining build.sh module list (with Peter and Alan) for a year now. </BODY> </HTML>