Re: XFree86 modularization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, 2003-05-09 at 10:43, David Dawes wrote:
> On Thu, May 08, 2003 at 09:25:39PM -0700, Torrey T. Lyons wrote:
> >At 11:47 PM -0400 5/8/03, Owen Taylor wrote:
> >>Hi Egbert,
> >>
> >>Here's a quick (if late) writeup of my thoughts on X modularization;
> >>I'm not sure it really addresses your questions, since the
> >>driver interfaces are the part of X that I'm least familiar
> >>with, but perhaps it is useful anyways.
> >>
> >>  * One thing I personally would to like to see split apart, or in
> >>    fact, killed from XFree86 is copies of libraries that are
> >>    independently maintained ... FreeType, zlib, expat, and now
> >>    fontconfig. People whine about external dependencies, but in
> >>    the end sucked in copies of the libraries do more harm both
> >>    maintenance headaches and in multiple conflicting installs.
> >
> >Here's a counter example: In recent history this would have caused 
> >great difficulties on Darwin/Mac OS X with Freetype. Freetype is 
> >largely only installed on Mac OS X as part of XFree86. Although 
> >Freetype supports Mac OS X, the Freetype team has no committers with 
> >a Mac OS X box. Until a few days ago you could not even build 
> >standard Freetype on Mac OS X using gcc but had to use a proprietary 
> >compiler. I do not mean to pick on the Freetype team--they do a great 
> >job. Freetype has just had a different emphasis with regards to which 
> >platforms they support. However, whenever XFree86 depends on an 
> >external library that may not have the same level of support for all 
> >the platforms XFree86 supports, you need to have XFree86 maintain a 
> >local copy of the library.
> As well as making sure that significant external dependencies are
> available in a sufficiently portable form to be useful for a product
> that spans as many platforms as XFree86 does, it's also important that
> such dependencies be available under licenses that are XFree86-compatible.
> Having them within the XFree86 source tree is an effective way of
> achieving all of this, as well as making it easy for a complete XFree86
> to be built without having to track a moving target of external
> dependencies.

I don't really understand how having the the dependencies in the XFree86
tree ensures that their license are X compatible; it seems to me
that needs to be decided when you decide to depend on the library :-)

And I'm not sure that the current set of XFree86 dependencies should
cause much worry about portability ... freetype/zlib/expat are all
used far beyond the portability bounds of XFree86.

I certainly understand the worry about external dependencies causing
difficulties for people building the system... it's a legitimate
issue, and we have a worse problem with it for GTK+ which has
roughly twice as many "external dependencies" as XFree86.

But I would argue that if you incorporate a copy of an external
library, you have the obligation *not* to install it in a way
that can affect the system.

When I use my own copy of a library within an executable,
I want to statically link to that library, or install a shared 
library into a location not on the system's search path.

When I incorporate my own copy of a library in a public library,
then I want to rename all publically exported symbols. GLib
does this for libcharset, Pango does it for 'fribidi'.

Leakage of FreeType onto the system library path (or for an
earlier example that caused a lot of pain for GNOME, of a partial
libzlib.a) is unfriendly to other software on the system.


> As for the argument about having multiple versions of things like freetype
> installed, XFree86 can be configured to build and use externally supplied
> version of externally maintained dependencies like freetype, so that is
> really a non-issue.  The approach XFree86 has taken on this provides
> workable solutions for all of its user base, not just today's largest
> subset.

If XFree86 automatically detected the presence of a system version
of FreeType at build time and used that, things would certainly be
better. That's the idea of pkg-config and .pc files ... to provide a
standard way of locating what's on the system.


Forum mailing list

[X.Org]     [XFree86]     [XFree86 Discussion]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Samba]     [Linux Security]     [Linux RAID]     [Linux Resources]

  Powered by Linux