[PATCH modular] Process a user-supplied list of module/components.

[Gaetan Nadon]

On Wed, 2010-10-06 at 16:16 -0400, Trevor Woerner wrote:

> I agree... but to be honest I think the more pertinent question is:
> why would a user be trying to build unknown sub-projects? Shouldn't
> all the projects be known to the build.sh script? Should the script
> even support unknown projects? If a new project is being added to the
> X.Org family, shouldn't it be patched into the build script the way
> the others are already?
> 
> > If it is not doable, we should have a way for users to quickly find
> out it's
> > the way it works so
> > he does not waste time debugging.
> 
> I'll think about ways to build unknown projects in whatever order
> they're specified, but I really think projects that aren't known to
> the script shouldn't be supported at all.
> 
> Let's say you're working on a new project to be added:
> "xf86-video-gaetan". I would hope that as part of your development you
> would determine where in the sub-project list it should be built, add
> it to the build.sh script, then submit it when you send in the patches
> for the rest of your work. In other words, if you're working on
> something locally that isn't yet available publicly, just patch your
> build.sh to support your new project, then send it in when the rest of
> your work gets accepted.
> 
> I was under the impression one of the most important things the
> build.sh script provides for the user is the ability to build all the
> sub-projects of X.Org in the correct order. So in that case no matter
> how the user supplies the list of projects they want built, the script
> should build them in the order it knows will work correctly. I think
> that's important to retain; more important than supporting
> sub-projects which aren't known to the script.
> 

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:

        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.

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







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101006/4e9e52ba/attachment.html>
-------------- 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/20101006/4e9e52ba/attachment-0001.pgp>