[PATCH modular] Implement a classification for scripts using subdirectories
Gaetan Nadon
memsize at videotron.ca
Wed Sep 22 17:40:14 PDT 2010
On Wed, 2010-09-22 at 17:01 -0400, Trevor Woerner wrote:
> I'm concerned about your wording; I hope I haven't come across as
> being opposed to or resisting your ideas on this matter.
>
Not at all, I just meant I was promoting the idea. Sorry for my poor
wording.
I did it twice in the same day :-(
> With regards to the module list, my understanding is that there are
> two issues:
>
> 1. what is the complete list of possible modules I could build for a
> given platform (e.g. linux-i386)
> 2. can the user provide a list to the build script of just the modules
> they want to see built
>
> "build.sh -L" provides you with the answer to #1.
>
> I have a patch to provide the functionality of #2, but I'm waiting to
> see what happens to the patch I provided a couple hours ago (perform
> arbitrary git or make commands) and the patch you provided to create
> subdirectories inside util/modular before submitting it. Additionally,
> the functionality of #2 uses the list of #1 to make sure the modules
> are built in the correct order irrespective of the order in which
> they're provided.
>
> > And if we were to have common module list, they perhaps should be in
> a
> > separate dir.
>
> The list of modules (and their order) inside the build.sh script isn't
> entirely static. It changes depending on which platform you are
> building for. So the list wouldn't be a static file, but rather would
> need some logic to be generated correctly. As I've said, "build.sh -L"
> provides you with this list.
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100922/0b7e139f/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/20100922/0b7e139f/attachment.pgp>
More information about the xorg-devel
mailing list