Modules created and initial files checked in

[Mike A. Harris]

Keith Packard wrote:
> On Mon, 2005-05-09 at 12:19 -0400, Kevin E Martin wrote:
> 
> 
>>That's a really good question.  When I created the initial proto module
>>components, I just used 7.0 for the version numbers to get the ball
>>rolling, but I think you're correct that it would be better to use the
>>library versions as a starting point for the corresponding proto
>>packages.  
> 
> 
> There are three version numbers here:
             ^^^^^
> 
>  1)  The X.org release number
>  2)  The protocol revision
>  3)  The library .so number
>  4)  The library version
    ^
Surely you meant to number them starting at offset 0?  ;o)

</runs>

> We would like to keep the library versions constant through multiple
> X.org releases (especially across 6.9 and 7.0), so we can't base the
> library versions on the X.org version
 >
> The .so version number will not necessarily be the same across different
> operating systems as it depends on both local convention and system
> capabilities.  So, we can't base the library version on the .so version
> number.

Both of these things make sense.  How about using pre-existing
library versions where they exist (ie: libXft, libXrender,
libkeithp*), and for libraries that have never had a version
separate from the Xorg release, start their package version
number at 1.0.  Since it's the first time such libraries will
have had their own package, it kindof makes sense for it to
start at 1.0.  The points you've brought up in the email, as
well as in other parts of the thread I think show that the
package version for most libraries is more or less an arbitrary
choice, because there isn't any universal rule that seems to
apply to them all in a clean way based on some pre-existing
version of something.

Calling say, libX11-1.0.tar.gz or something thereabouts doesn't
mean it's the first version of libX11 of course, just the first
version of the libX11 modular library package.  I think this
would work out fairly well.  Can anyone think of a real problem
this would cause?


> lets keep all of the module names lower case only so that the module
> name exactly matches the pkg-config file name.
> 
> I realize our library names include upper case letters, but we shouldn't
> take that as an opportunity to spread the confusion elsewhere.

Indeed.  This is a point I've always found confusing in X-land, and
I've never seen a really rational explanation of the naming
semantics of libraries/extensions.  It certainly doesn't seem like
there's one being followed anyway.  ;o)

For a given extension, we often see extension FOO or X-FOO, with
libFoo (or libfoo, or libXfoo, or libXFoo), with foo.h, Foo.h,
Xfoo.h or XFoo.h as it's header, with seemingly no coorelation
between the case used by the lib and the header, with the directories
named differring in capitalization, or either removing or adding
the X or x to the front of it.

It's too bad this wasn't ever standardized and kept standard
throughout the X11 source tree since it's inception.  ;o)

Now there's also Xorg, XOrg, X.Org, X.org, x.org, xorg, xorg.conf,
Xorg.0.log to add to the mixed case confusion.  ;o)

Perhaps we should make X11R7 have a primary goal of renaming all
of the stock files to be completely lowercase, and outlaw mixed
case completely.  ;o)

Ok, I'm being crazy now - but only 1/2 crazy.  ;o)