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

[Egbert Eich]

Owen Taylor writes:
 > > 
 > > We removed the dependency on internal headers. 
 > 
 > Really? I still see the inclusion in:
 > 
 > http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/lib/font/FreeType/ftfuncs.c?rev=1.5&view=auto
 > 

OK, you seem to be referring to:
#include FT_INTERNAL_TRUETYPE_TYPES_H
#include FT_INTERNAL_SFNT_H
#include FT_INTERNAL_STREAM_H
The last one at least doesn't seem to be required.

The question arises how private those headers are.

 > > However the question
 > > arises what is an internal header. If you install a header in 
 > > /usr/include/... it is no longer internal.
 > 
 > And if you install a header into
 > /usr/include/freetype2/freetype/internal/?
 > 
 > While I wouldn't recommend installing internal headers, I think if
 > an application does:
 >  
 > #include FT_INTERNAL_TRUETYPE_TYPES_H
 > 
 > They are definitely asking for trouble.

So why are these headers installed, then?

I think saying "well, these are not really ment to be public
so we reserve the right to change them but application may still find
them useful" calls for trouble.

 > 
 > >  > (Pango also uses internal headers but with implicit acceptance of
 > >  > the risk that if you upgrade FreeType you may also need to upgrade
 > >  > Pango.)
 > > 
 > > This issue should be fixed with the freetype folks. If interfaces are
 > > exposed thru the headers in /usr/include/.. they should not be considered
 > > internally. If one needs the freetype sources (we did prior to X.Org 6.7)
 > > to build because he needs a header file that doesn't get installed,
 > > one should talk to FreeType to make this information public.
 > > That's what Chisato did.
 > 
 > The Pango question is a little different - Pango includes a big hunk of
 > table reading code from FreeType 1 ported to Pango 2. The plan is to get
 > it back into the FreeType project, but that's a long term thing. 
 > Anyways, not really the subject here...

Right. We should do the same thing and supply a patch freetype that
makes it public.
It won't help us to fix the past, though, but we can fix the past 
by adding backward compatibility #ifdefs. Knowing that we will 
not have to clutter the code with these for an unforseeable future 
helps to justify them.

[...]
 > 
 > I don't think that the rebuilding half the packages installed is
 > will be necessary. FreeType-2.0 => FreeType-2.1 might have required
 > rebuilding Pango (I don't recall at this point.) I'm pretty sure
 > we didn't need to rebuild anything else in the distribution.
 > And no other upgrades of FreeType required rebuilding packages.

Appearantly there was a problem between 2.1.6 and 2.1.7 and there
are indications that there also is a problem between 2.1.7 and 2.1.8.

 > 
 > [...]
 > 
[...]

 > > 
 > > Then this begs the question why people have to access internal structures
 > > and why they are exposed thru external headers in the first place.
 > 
 > Well if you look at why ftfuncs.c is using internal headers, I think
 > it's because new functionality was written as if it was part of 
 > FreeType - probably so it could be submitted as an addition to FreeType.
 > 
 > We could certainly campaign to have FreeType move more stuff to the
 > public supported API... to make FreeType a more extensible library.
 > But I think new functionality is seldom going to be *required* for X,
 > so a better approach is probably:
 >  
 >  - When new functionality is useful, submit a patch to freetype to
 >    add that functionality.
 >  - Add conditionalization to X to use that functionality when
 >    there and fallback when not.

Right.

[...]

 > > 
 > > I can see a problem when the later one is used during build while the
 > > earlier version is used during run time.
 > > The other way around shouldn't be a problem provided the backward
 > > compatibility issue is resolved.
 > 
 > If the mismatch happens the right way, there's no problem. But it
 > happens the wrong way roughly 50% of the time...
 > 
 > >  > [ I'll certainly loudly oppose the motion if you encourage the FreeType
 > >  >   maintainers to bump the major version number :-). That would be
 > >  >   a horrible pain for distributors ]
 > >  > 
 > > 
 > > This has happend with other libs before and has forced distributors to
 > > ship old versions of these libs along with the newest ones anyhow.
 > 
 > Yes, but usually major version number changes go along with significant
 > API changes. A new major version of a library more than doubles the
 > maintenance for distributions (I have to *backport* fixes to the
 > old version...). Having that cost for no real gain isn't pretty.
 > 

OK, that's definitely annoying. But how often does it happen that 
a patch is importand enough to be backported to an older version?

Cheers,
	Egbert.