Re: regtests for previous stables failing

[Thomas Morley]

2017-10-29 8:44 GMT+01:00 Werner LEMBERG <address@hidden>:
>>> But I get
>>> /home/hermann/lilypond-git/lily/pango-font.cc: In member function
>>> 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*)
>>> const':
>>> /home/hermann/lilypond-git/lily/pango-font.cc:166:55: error:
>>> 'FT_Get_X11_Font_Format' was not declared in this scope
>>>    bool is_ttf = string (FT_Get_X11_Font_Format (ftface)) == "TrueType";
>>>
>>> A gcc-version-problem?
>>
>> More likely a freetype problem.
>
> Actually, it could be indeed a gcc version problem (or rather, a cpp
> problem).  In `pango-font.cc' we have
>
>   #include FT_XFREE86_H
>
> which is defined by FreeType as
>
>     /* deprecated */
>   #define FT_XFREE86_H  FT_FONT_FORMATS_H
>
> which in turn is defined as
>
>   #define FT_FONT_FORMATS_H  <freetype/ftfntfmt.h>
>
> Using gcc 4.8.5 for compilation of lilypond works just fine on my
> GNU/Linux box, BTW.
>
> Maybe it helps if you replace the line
>
>   #include FT_XFREE86_H
>
> in file `pango-font.cc' with
>
>   #include FT_FONT_FORMATS_H
>
> If this compiles successfully, you definitely have a cpp bug in the
> gcc version you use.
>
>
>     Werner

Hi Werner,

I was trying to compile old branches (stable/2.16 and stable/2.18)
with the software Ubuntu 16.04 distributes. So I'm not at bleeding
edge but far more up to date than back in the time 2.16 was released.
You could say I tried a manual bisect limited to large steps.

While 2.18 was successful applying compatibility-pathes, i.e.
  Issue 4364: Allow ImageMagick's compare to exit with status 1
  Build: Fix compilation with GNU make 4.0
2.16 failed so far.

Your patch
  Issue 3694: Use standard inclusion scheme for FreeType headers.
didn't apply to 2.16. so I tried to insert the code manually, which
seems to cure the above reported problem.
But I now get errors in texi-files like:
@itemx must follow @item
warning: @vindex should only appear at a line beginning (possibly
involving @rweb)
raising the section level of @unnumberedsubsubsec which is too low
...

I don't think it makes sense to continue trying to compile 2.16 with
recent versions of make, gcc etc

Using makepp may have some advantages for future development
(honestly, I don't know anything about it) but I can't see how it
could help with that old code.


Anyway, thanks a lot to all,
  Harm