[Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has nomembernamed `find_sbit_image'

[Jim Gettys]

On Fri, 2004-07-30 at 08:44, Roland Mainz wrote:
> Matthieu Herrb wrote:
> > >>>"Things slow down (a lot) for some fonts when used as core fonts" is
> > >>>*far* better than "The build fails for almost all of our users."
> > >>>Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> > >>>pretty simple to me.
> > >>
> > >>Seconded, FWIW.
> > >
> > > So you think it's acceptable to slap the users in asia into the face or
> > > what ? Those users get a font loading performance which is *NOT*
> > > acceptable if that code gets removed again.
> > 
> > I'd suggest to let imake detect the version of the installed Freetype,
> > and then disable the offending  code if the installed version is too old.
> 
> That's the option I'd like to avoid. Just think about it: The last
> release (="Xorg release 6.7.0") made Freetyppe 2.1.7 _mandatory_. So why
> it is a problem to make FreeType 2.1.8 mandatory (one revision newer
> than the previous release "minimum" version) for the next "major"
> release - "6.8.0". Otherwise we can really call it "Xorg release 6.7.1"
> ... =:-)

I see no problem with requiring more recent freetypes, (or other
dependencies) when there are good reasons.

I do see major problems with privately patched versions of dependencies.
Are we to start shipping libc if there are bugs? Or libm?

Good open source behavior involves good citizenship with allied
projects: I think we need to grow up and work in the larger community.

And given we have a freetype dependency, I think it behooves us to
try to work with the freetype project to detect regressions in their
library *before* it breaks us (or our users in the field).  I suspect
that they'd be very happy to see such testing done in a systematic
fashion, rather than the haphazard fashion to date.  (who knows, maybe
we can encourage them to run one or more tinderclients ;-)).

And breaking the build isn't a good situation.  I know we've not yet
worked out policy around broken builds (now that we can detect them); on
many projects, on at least the core development platforms, if the build
is broken, no further check-ins are even permitted, and I suspect such a
policy might serve us well.  But to do this, we have to work out what
our version dependencies are.

> 
> > BTW, another problem seem to be that mozilla (and thunderbird) builds
> > fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
> > and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
> > known workaround for that?
> 
> Not really. Someone wrote patches but they only work with FreeType
> 2.1.8. That's why I start to like the idea with linking the library
> statically into the font code, otherwise the next FreeType2 release may
> cause headache again...

Here lies madness.  So in parts of the world that the Apple hinting
patent does not apply, users are supposed to rebuild X? (not to mention
other bugs that may only be discovered later being un-fixable). 
Statically linking private copies just delays the pain, and makes it
harder to fix.
                                      - Jim