[Lsb-infrastructure] problem with freetype headers

[Denis Silakov]

Well, I see that one of the main problems here is that mkheader tries to
make every header all-sufficient. I.e. you can include generated header
and do not worry about its dependencies - they all are included in the
header itself.

Sometimes headers have mutual - you can include one header in the other
one only after declaring some necessary types. mkheader can resolve some
kind of such dependencies, but in case of freetype they are too deep for
the script; for example, we have the follwoinf chain for the freetype.h:

freetype.h -> ftimage.h -> ftoutln.h -> ftglyph.h -> freetype.h

mkheader didn't resolve this chain, so all includes are made in the
beginning of the files. However, ftglyph.h does require some types from
freetype.h to be declared.


Wichmann, Mats D wrote:
> I was reminded when I generated the new headers for
> devel/build_env that there are three freetype headers
> which are hand edited.  I chatted with Alexey about
> this today, we should find a way to fix.  This one is 
> my fault; some of you remember I was trying to get a
> nearly year-old import left by the old desktop group
> integrated for 3.2, but had to do some work by hand
> since the old tools weren't so good, and things had
> changed underneath.  I ended up with three generated
> headers which generate pieces in an order which does
> not allow them to compile: used-before-defined errors
> and, I think, some #include issues.  I should of course
> have fixed this instead of hacking headers by hand, 
> but I didn't, under time pressure.
>
> I'm dropping this note here so the issue is a little
> more widely known, and attaching a diff of the three
> headers between what generated from the DB and what
> is hand-edited and in bzr  - the order in the diff is
> in a sense reversed from what one would expect, but
> a line at the top should show that.
>
>   
-- 

Regards,
Denis.