Staging broken.

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Staging broken.

David Kastrup

Hi, staging does not compile anymore.

Making lily/out/keyword.o < cc
Making lily/out/simple-spacer-scheme.o < cc
Making lily/out/episema-engraver.o < cc
Making lily/out/lyric-extender.o < cc
Making lily/out/includable-lexer.o < cc
Making lily/out/timing-translator.o < cc
Making lily/out/pango-font.o < cc
Making lily/out/part-combine-part-iterator.o < cc
Making lily/out/horizontal-bracket.o < cc
/tmp/lilypond-autobuild/lily/pango-font.cc: In member function 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*) const':
/tmp/lilypond-autobuild/lily/pango-font.cc:229:28: error: invalid use of incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
  229 |   FcPattern *fcpat = fcfont->font_pattern;
      |                            ^~
In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
                 from /tmp/lilypond-autobuild/lily/pango-font.cc:20:
/usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
   47 | typedef struct _PangoFcFont      PangoFcFont;
      |                ^~~~~~~~~~~~
Making lily/out/clef-engraver.o < cc
Making lily/out/key-performer.o < cc
make[1]: *** [/tmp/lilypond-autobuild/stepmake/stepmake/c++-rules.make:5: out/pango-font.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [/tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6: all] Error 2

I'll back out the Pango related commit and retry.  It is a bit of a
puzzler to me how this could have passed testing.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
David Kastrup <[hidden email]> writes:

> Hi, staging does not compile anymore.
>
> Making lily/out/keyword.o < cc
> Making lily/out/simple-spacer-scheme.o < cc
> Making lily/out/episema-engraver.o < cc
> Making lily/out/lyric-extender.o < cc
> Making lily/out/includable-lexer.o < cc
> Making lily/out/timing-translator.o < cc
> Making lily/out/pango-font.o < cc
> Making lily/out/part-combine-part-iterator.o < cc
> Making lily/out/horizontal-bracket.o < cc
> /tmp/lilypond-autobuild/lily/pango-font.cc: In member function
> 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*)
> const':
> /tmp/lilypond-autobuild/lily/pango-font.cc:229:28: error: invalid use
> of incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
>   229 |   FcPattern *fcpat = fcfont->font_pattern;
>       |                            ^~
> In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
>                  from /tmp/lilypond-autobuild/lily/pango-font.cc:20:
> /usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
>    47 | typedef struct _PangoFcFont      PangoFcFont;
>       |                ^~~~~~~~~~~~
> Making lily/out/clef-engraver.o < cc
> Making lily/out/key-performer.o < cc
> make[1]: ***
> [/tmp/lilypond-autobuild/stepmake/stepmake/c++-rules.make:5:
> out/pango-font.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [/tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6: all] Error 2
>
> I'll back out the Pango related commit and retry.  It is a bit of a
> puzzler to me how this could have passed testing.

Actually, both Pango related commits.  Turns out that the "Make Pango
>= 1.36 mandatory" commit is responsible, likely by throwing out
required tests/definitions, and it is my guess that the other Pango
commit depends on that.

Probably the tests forgot to reconfigure, and it is in the configuration
phase that the defines were removed.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

pkx166h-4
Hello,

On 18.02.2020 11:59, David Kastrup wrote:

> David Kastrup <[hidden email]> writes:
>
>> Hi, staging does not compile anymore.
>>
>> Making lily/out/keyword.o < cc
>> Making lily/out/simple-spacer-scheme.o < cc
>> Making lily/out/episema-engraver.o < cc
>> Making lily/out/lyric-extender.o < cc
>> Making lily/out/includable-lexer.o < cc
>> Making lily/out/timing-translator.o < cc
>> Making lily/out/pango-font.o < cc
>> Making lily/out/part-combine-part-iterator.o < cc
>> Making lily/out/horizontal-bracket.o < cc
>> /tmp/lilypond-autobuild/lily/pango-font.cc: In member function
>> 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*)
>> const':
>> /tmp/lilypond-autobuild/lily/pango-font.cc:229:28: error: invalid use
>> of incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
>>   229 |   FcPattern *fcpat = fcfont->font_pattern;
>>       |                            ^~
>> In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
>>                  from /tmp/lilypond-autobuild/lily/pango-font.cc:20:
>> /usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward
>> declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
>>    47 | typedef struct _PangoFcFont      PangoFcFont;
>>       |                ^~~~~~~~~~~~
>> Making lily/out/clef-engraver.o < cc
>> Making lily/out/key-performer.o < cc
>> make[1]: ***
>> [/tmp/lilypond-autobuild/stepmake/stepmake/c++-rules.make:5:
>> out/pango-font.o] Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> make: ***
>> [/tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6:
>> all] Error 2
>>
>> I'll back out the Pango related commit and retry.  It is a bit of a
>> puzzler to me how this could have passed testing.

Actually if you look on the tracker you'll see that I wrote

'Passes make, make test-baseline, and a full make doc.'

This is probably my fault misunderstanding what can and what cannot be
'tested' after 'configure' has been run.

For example, as far as I can remember/tell if I *.ac files are patched
then when I run

./autogen.sh --noconfigure
mkdir build
cd build
../configure
make
make test-baseline

and THEN I try to apply the diff, I get some 'error' about the file
being newer (or something, I cannot recall without doing it) as when you
run the patch tests you are not re-running autogen/configure.

I am not versed enough to probably articulate myself here, but anyway, I
assumed that I could never patch any of the make/config files because
they never get re-done for the workflow that I have been using.

So I just apply these 'make file' patches to master and build from that
without the make check (this way I figured at least that I'd test most
of the patch because it would still have to build the reg tests and the
docs).

So sorry for that. Obviously I need some education here.

James
---
Regards

James



Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
James <[hidden email]> writes:

> Hello,
>
> On 18.02.2020 11:59, David Kastrup wrote:
>> David Kastrup <[hidden email]> writes:
>>
>>> Hi, staging does not compile anymore.
>>> Making lily/out/keyword.o < cc
>>> Making lily/out/simple-spacer-scheme.o < cc
>>> Making lily/out/episema-engraver.o < cc
>>> Making lily/out/lyric-extender.o < cc
>>> Making lily/out/includable-lexer.o < cc
>>> Making lily/out/timing-translator.o < cc
>>> Making lily/out/pango-font.o < cc
>>> Making lily/out/part-combine-part-iterator.o < cc
>>> Making lily/out/horizontal-bracket.o < cc
>>> /tmp/lilypond-autobuild/lily/pango-font.cc: In member function
>>> 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*)
>>> const':
>>> /tmp/lilypond-autobuild/lily/pango-font.cc:229:28: error: invalid use
>>> of incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
>>>   229 |   FcPattern *fcpat = fcfont->font_pattern;
>>>       |                            ^~
>>> In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
>>>                  from /tmp/lilypond-autobuild/lily/pango-font.cc:20:
>>> /usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward
>>> declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
>>>    47 | typedef struct _PangoFcFont      PangoFcFont;
>>>       |                ^~~~~~~~~~~~
>>> Making lily/out/clef-engraver.o < cc
>>> Making lily/out/key-performer.o < cc
>>> make[1]: ***
>>> [/tmp/lilypond-autobuild/stepmake/stepmake/c++-rules.make:5:
>>> out/pango-font.o] Error 1
>>> make[1]: *** Waiting for unfinished jobs....
>>> make: ***
>>> [/tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6:
>>> all] Error 2
>>> I'll back out the Pango related commit and retry.  It is a bit of a
>>> puzzler to me how this could have passed testing.
>
> Actually if you look on the tracker you'll see that I wrote
>
> 'Passes make, make test-baseline, and a full make doc.'
>
> This is probably my fault misunderstanding what can and what cannot be
> 'tested' after 'configure' has been run.

Everything?

> For example, as far as I can remember/tell if I *.ac files are patched
> then when I run
>
> ./autogen.sh --noconfigure
> mkdir build
> cd build
> ../configure
> make
> make test-baseline
>
> and THEN I try to apply the diff, I get some 'error' about the file
> being newer (or something, I cannot recall without doing it) as when
> you run the patch tests you are not re-running autogen/configure.

Why would you not rerun autogen/configure?

The procedure for a patch would be

git apply --index xxxx.diff
./autogen.sh --noconf
cd build
../configure --enable-checking  # and/or other desired options
make clean test-clean doc-clean
CPU_COUNT=9 make -j9 # or whatever other options
CPU_COUNT=9 make -j9 check
CPU_COUNT=9 make -j9 doc

If you want to be sure to rerun configure with the same options, you can
use

../config.status --recheck

assuming that you still have the results from last run.

> I am not versed enough to probably articulate myself here, but anyway,
> I assumed that I could never patch any of the make/config files
> because they never get re-done for the workflow that I have been
> using.

Well, I have no idea what went wrong when you tried redoing them.  We
probably need to figure that out.  I think you already reported this but
got no response or helpful suggestions at that time.

> So sorry for that. Obviously I need some education here.

I think we just need to figure out where and when and why things went
off-rail.  It's probably something simple that should have been easy to
fix long ago if I or somebody else had bothered listening.  Sorry.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Han-Wen Nienhuys-3
In reply to this post by David Kastrup
This surprises me greatly. I just checked
out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
morning,  and I can execute

 ./autogen.sh ; make -j4

just fine. In fact, I actually did test this before pushing this morning.

Could it be that you forgot to run autogen.sh ?


On Tue, Feb 18, 2020 at 11:51 AM David Kastrup <[hidden email]> wrote:

>
> Hi, staging does not compile anymore.
>
> Making lily/out/keyword.o < cc
> Making lily/out/simple-spacer-scheme.o < cc
> Making lily/out/episema-engraver.o < cc
> Making lily/out/lyric-extender.o < cc
> Making lily/out/includable-lexer.o < cc
> Making lily/out/timing-translator.o < cc
> Making lily/out/pango-font.o < cc
> Making lily/out/part-combine-part-iterator.o < cc
> Making lily/out/horizontal-bracket.o < cc
> /tmp/lilypond-autobuild/lily/pango-font.cc: In member function 'Stencil
> Pango_font::pango_item_string_stencil(const PangoGlyphItem*) const':
> /tmp/lilypond-autobuild/lily/pango-font.cc:229:28: error: invalid use of
> incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
>   229 |   FcPattern *fcpat = fcfont->font_pattern;
>       |                            ^~
> In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
>                  from /tmp/lilypond-autobuild/lily/pango-font.cc:20:
> /usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward
> declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
>    47 | typedef struct _PangoFcFont      PangoFcFont;
>       |                ^~~~~~~~~~~~
> Making lily/out/clef-engraver.o < cc
> Making lily/out/key-performer.o < cc
> make[1]: *** [/tmp/lilypond-autobuild/stepmake/stepmake/c++-rules.make:5:
> out/pango-font.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: ***
> [/tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6: all]
> Error 2
>
> I'll back out the Pango related commit and retry.  It is a bit of a
> puzzler to me how this could have passed testing.
>
> --
> David Kastrup
>
>

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Han-Wen Nienhuys-3
I double checked, and it compiles at
b16c3d14f3d1f10aa919e70107e6103c67a9aa01 without error in a clean directory
as well.

Could you provide instructions how I can reproduce this build breakage?

thanks,

On Tue, Feb 18, 2020 at 10:56 PM Han-Wen Nienhuys <[hidden email]> wrote:

> This surprises me greatly. I just checked
> out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
> morning,  and I can execute
>
>  ./autogen.sh ; make -j4
>
> just fine. In fact, I actually did test this before pushing this morning.
>
> Could it be that you forgot to run autogen.sh ?
>
>
> On Tue, Feb 18, 2020 at 11:51 AM David Kastrup <[hidden email]> wrote:
>
>>
>> Hi, staging does not compile anymore.
>>
>> Making lily/out/keyword.o < cc
>> Making lily/out/simple-spacer-scheme.o < cc
>> Making lily/out/episema-engraver.o < cc
>> Making lily/out/lyric-extender.o < cc
>> Making lily/out/includable-lexer.o < cc
>> Making lily/out/timing-translator.o < cc
>> Making lily/out/pango-font.o < cc
>> Making lily/out/part-combine-part-iterator.o < cc
>> Making lily/out/horizontal-bracket.o < cc
>> /tmp/lilypond-autobuild/lily/pango-font.cc: In member function 'Stencil
>> Pango_font::pango_item_string_stencil(const PangoGlyphItem*) const':
>> /tmp/lilypond-autobuild/lily/pango-font.cc:229:28: error: invalid use of
>> incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
>>   229 |   FcPattern *fcpat = fcfont->font_pattern;
>>       |                            ^~
>> In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
>>                  from /tmp/lilypond-autobuild/lily/pango-font.cc:20:
>> /usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward
>> declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
>>    47 | typedef struct _PangoFcFont      PangoFcFont;
>>       |                ^~~~~~~~~~~~
>> Making lily/out/clef-engraver.o < cc
>> Making lily/out/key-performer.o < cc
>> make[1]: *** [/tmp/lilypond-autobuild/stepmake/stepmake/c++-rules.make:5:
>> out/pango-font.o] Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> make: ***
>> [/tmp/lilypond-autobuild/stepmake/stepmake/generic-targets.make:6: all]
>> Error 2
>>
>> I'll back out the Pango related commit and retry.  It is a bit of a
>> puzzler to me how this could have passed testing.
>>
>> --
>> David Kastrup
>>
>>
>
> --
> Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
>


--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
In reply to this post by Han-Wen Nienhuys-3
Han-Wen Nienhuys <[hidden email]> writes:

> This surprises me greatly. I just checked
> out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
> morning,  and I can execute
>
>  ./autogen.sh ; make -j4
>
> just fine. In fact, I actually did test this before pushing this morning.
>
> Could it be that you forgot to run autogen.sh ?

lilypond-patchy-staging starts from a fresh directory, so no.  It
wouldn't get anywhere without running autogen.sh.

I cannot vouch for all software versions being the same as yours,
obviously.

Did you run make clean ?

Versions installed here:

ii  libpango1.0-dev:amd64      1.42.4-7        amd64        Development files for the Pango

Also libguile-1.8, but I consider it unlikely that this changes the used
include files.

You removed several defines that I think Werner added at some point of
time in order to deal with newer versions of Freetype.

I read in the patch:

 AC_DEFUN(STEPMAKE_PANGO_FT2, [
     PKG_CHECK_MODULES(PANGO_FT2, $1 >= $3, have_pangoft2=yes, true)
     if test "$have_pangoft2" = yes ; then
-        AC_DEFINE(HAVE_PANGO16)
-        AC_DEFINE(HAVE_PANGO_FT2)
         # Do not pollute user-CPPFLAGS with configure-CPPFLAGS
         save_CPPFLAGS="$CPPFLAGS"
         save_LIBS="$LIBS"
@@ -1328,8 +1300,6 @@ AC_DEFUN(STEPMAKE_PANGO_FT2_WITH_OTF_FEATURE, [
     PKG_CHECK_MODULES(PANGO_FT2, $1 >= $3,
         have_pangoft2_with_otf_feature=yes, true)
     if test "$have_pangoft2_with_otf_feature" = yes; then
-        AC_DEFINE(HAVE_PANGO16)
-        AC_DEFINE(HAVE_PANGO_FT2)
         AC_DEFINE(HAVE_PANGO_FT2_WITH_OTF_FEATURE)


Any reason for that?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Han-Wen Nienhuys-3
On Tue, Feb 18, 2020 at 11:08 PM David Kastrup <[hidden email]> wrote:

> Han-Wen Nienhuys <[hidden email]> writes:
>
> > This surprises me greatly. I just checked
> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
> > morning,  and I can execute
> >
> >  ./autogen.sh ; make -j4
> >
> > just fine. In fact, I actually did test this before pushing this morning.
> >
> > Could it be that you forgot to run autogen.sh ?
>
> lilypond-patchy-staging starts from a fresh directory, so no.  It
> wouldn't get anywhere without running autogen.sh.
>

The build log talks about

autogen.sh --noconfigure

can you confirm that with "   ./autogen.sh && make -j4" it also fails?

I cannot vouch for all software versions being the same as yours,
> obviously.
>

Can you provide me with some recipe to reproduce the problem? Can you tell
me what distribution you use? I could use Docker to recreate your setup.


> Did you run make clean ?
>

I ran from a clean checkout as well.


> Versions installed here:
>
> ii  libpango1.0-dev:amd64      1.42.4-7        amd64        Development
> files for the Pango
>
> Also libguile-1.8, but I consider it unlikely that this changes the used
> include files.
>
> You removed several defines that I think Werner added at some point of
> time in order to deal with newer versions of Freetype.
>
> I read in the patch:
>
>  AC_DEFUN(STEPMAKE_PANGO_FT2, [
>      PKG_CHECK_MODULES(PANGO_FT2, $1 >= $3, have_pangoft2=yes, true)
>      if test "$have_pangoft2" = yes ; then
> -        AC_DEFINE(HAVE_PANGO16)
> -        AC_DEFINE(HAVE_PANGO_FT2)
>          # Do not pollute user-CPPFLAGS with configure-CPPFLAGS
>          save_CPPFLAGS="$CPPFLAGS"
>          save_LIBS="$LIBS"
> @@ -1328,8 +1300,6 @@ AC_DEFUN(STEPMAKE_PANGO_FT2_WITH_OTF_FEATURE, [
>      PKG_CHECK_MODULES(PANGO_FT2, $1 >= $3,
>          have_pangoft2_with_otf_feature=yes, true)
>      if test "$have_pangoft2_with_otf_feature" = yes; then
> -        AC_DEFINE(HAVE_PANGO16)
> -        AC_DEFINE(HAVE_PANGO_FT2)
>          AC_DEFINE(HAVE_PANGO_FT2_WITH_OTF_FEATURE)
>
>
> Any reason for that?
>

HAVE_PANGO16 was unused.

I effectively made HAVE_PANGO_FT2 always be true.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup <[hidden email]> wrote:
>
>> Han-Wen Nienhuys <[hidden email]> writes:
>>
>> > This surprises me greatly. I just checked
>> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
>> > morning,  and I can execute
>> >
>> >  ./autogen.sh ; make -j4
>> >
>> > just fine. In fact, I actually did test this before pushing this morning.
>> >
>> > Could it be that you forgot to run autogen.sh ?
>>
>> lilypond-patchy-staging starts from a fresh directory, so no.  It
>> wouldn't get anywhere without running autogen.sh.
>>
>
> The build log talks about
>
> autogen.sh --noconfigure
>
> can you confirm that with "   ./autogen.sh && make -j4" it also fails?
>
> I cannot vouch for all software versions being the same as yours,
>> obviously.
>>
>
> Can you provide me with some recipe to reproduce the problem? Can you tell
> me what distribution you use? I could use Docker to recreate your setup.

Just current Ubuntu eoan.

dak@lola:/usr/local/tmp/lilypond$ git worktree add ../lilypond3 bad-staging
Preparing worktree (checking out 'bad-staging')
HEAD is now at b16c3d14f3 Fix portuguese in input/regression/utf-8.ly
dak@lola:/usr/local/tmp/lilypond$ cd ../lilypond3/
dak@lola:/usr/local/tmp/lilypond3$ ./autogen.sh GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config GUILE=/usr/bin/guile

[...]

configure: creating ./config.status
config.status: creating config.make
config.status: creating config.hh

WARNING: Please consider installing optional programs or files:  URW++ OTF fonts (download OTF files from 'http://git.ghostscript.com/?p=urw-core35-fonts.git;a=tree;hb=91edd6ece36e84a1c6d63a1cf63a1a6d84bd443a' and put them under '~/.local/share/fonts' etc., or use --with-urwotf-dir) guile < 1.9.0 (installed: 2.2.6) tidy

See INSTALL.txt for more information on how to build LilyPond

Type:
    make all       to build LilyPond
    make install   to install LilyPond
    make help      to see all possible targets

Edit local.make for local Makefile overrides.

make -j4

[...]

Making lily/out/relocate.o < cc
Making lily/out/pango-font.o < cc
Making lily/out/part-combine-part-iterator.o < cc
pango-font.cc: In member function 'Stencil Pango_font::pango_item_string_stencil(const PangoGlyphItem*) const':
pango-font.cc:229:28: error: invalid use of incomplete type 'PangoFcFont' {aka 'struct _PangoFcFont'}
  229 |   FcPattern *fcpat = fcfont->font_pattern;
      |                            ^~
In file included from /usr/include/pango-1.0/pango/pangoft2.h:29,
                 from pango-font.cc:20:
/usr/include/pango-1.0/pango/pangofc-font.h:47:16: note: forward declaration of 'PangoFcFont' {aka 'struct _PangoFcFont'}
   47 | typedef struct _PangoFcFont      PangoFcFont;
      |                ^~~~~~~~~~~~
make[1]: *** [/usr/local/tmp/lilypond3/stepmake/stepmake/c++-rules.make:5: out/pango-font.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [/usr/local/tmp/lilypond3/stepmake/stepmake/generic-targets.make:6: all] Error 2


By the way, I'd configure using --enable-checking (which is implied when
using --disable-optimising) but it bombs out either way.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
David Kastrup <[hidden email]> writes:

> Han-Wen Nienhuys <[hidden email]> writes:
>
>> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup <[hidden email]> wrote:
>>
>>> Han-Wen Nienhuys <[hidden email]> writes:
>>>
>>> > This surprises me greatly. I just checked
>>> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed this
>>> > morning,  and I can execute
>>> >
>>> >  ./autogen.sh ; make -j4
>>> >
>>> > just fine. In fact, I actually did test this before pushing this morning.
>>> >
>>> > Could it be that you forgot to run autogen.sh ?
>>>
>>> lilypond-patchy-staging starts from a fresh directory, so no.  It
>>> wouldn't get anywhere without running autogen.sh.
>>>
>>
>> The build log talks about
>>
>> autogen.sh --noconfigure
>>
>> can you confirm that with "   ./autogen.sh && make -j4" it also fails?
>>
>> I cannot vouch for all software versions being the same as yours,
>>> obviously.
>>>
>>
>> Can you provide me with some recipe to reproduce the problem? Can you tell
>> me what distribution you use? I could use Docker to recreate your setup.
>
> Just current Ubuntu eoan.

The following patch makes the commit you pushed compile:

diff --git a/lily/pango-font.cc b/lily/pango-font.cc
index 8eece690c8..587ed3d4f3 100644
--- a/lily/pango-font.cc
+++ b/lily/pango-font.cc
@@ -17,6 +17,10 @@
   along with LilyPond.  If not, see <http://www.gnu.org/licenses/>.
 */
 
+// Necessary for supporting pango_context_new() and
+// pango_context_set_font_map() in Pango < 1.22
+#define PANGO_ENABLE_BACKEND
+
 #include <pango/pangoft2.h>
 #include "freetype.hh"
 #include FT_XFREE86_H


Never trust a comment.  It would seem that without that define, one
would need to include more/other/different headers to get the used types
defined.  At least in the Pango version I have installed.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Lukas-Fabian Moser
In reply to this post by Han-Wen Nienhuys-3

> The build log talks about
>
> autogen.sh --noconfigure
>
> can you confirm that with "   ./autogen.sh && make -j4" it also fails?

Fwiw, I had the same compile error as David yesterday. (It had been
quite a while since I last pulled & compiled, so I was not very much
surprised when make didn't succeed - I was halfway into trying to bisect
to find out just when in the last few months it stopped working on my
system when David's staging-broken alert arrived.)

My system is a down-to-earth Mint 19.3.

Lukas


Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
Lukas-Fabian Moser <[hidden email]> writes:

>> The build log talks about
>>
>> autogen.sh --noconfigure
>>
>> can you confirm that with "   ./autogen.sh && make -j4" it also fails?
>
> Fwiw, I had the same compile error as David yesterday. (It had been
> quite a while since I last pulled & compiled, so I was not very much
> surprised when make didn't succeed - I was halfway into trying to
> bisect to find out just when in the last few months it stopped working
> on my system when David's staging-broken alert arrived.)
>
> My system is a down-to-earth Mint 19.3.

Color me curious: why would you try building staging?  The whole point
of the staging system was to avoid breakage for developers.  Only patchy
processes are supposed to care about staging.

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Jonas Hahnfeld
In reply to this post by David Kastrup
Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:

> James <
> [hidden email]
> > writes:
> > Actually if you look on the tracker you'll see that I wrote
> >
> > 'Passes make, make test-baseline, and a full make doc.'
> >
> > This is probably my fault misunderstanding what can and what cannot be
> > 'tested' after 'configure' has been run.
>
> Everything?
>
> > For example, as far as I can remember/tell if I *.ac files are patched
> > then when I run
> >
> > ./autogen.sh --noconfigure
> > mkdir build
> > cd build
> > ../configure
> > make
> > make test-baseline
> >
> > and THEN I try to apply the diff, I get some 'error' about the file
> > being newer (or something, I cannot recall without doing it) as when
> > you run the patch tests you are not re-running autogen/configure.
>
> Why would you not rerun autogen/configure?
>
> The procedure for a patch would be
>
> git apply --index xxxx.diff
> ./autogen.sh --noconf
> cd build
> ../configure --enable-checking  # and/or other desired options
> make clean test-clean doc-clean
> CPU_COUNT=9 make -j9 # or whatever other options
> CPU_COUNT=9 make -j9 check
> CPU_COUNT=9 make -j9 doc
In my experience this doesn't work in all cases. I just switched back
from branch where I worked on the build system and here's what I get
(after running $ autoconf in the src directory):
 $ ../src/configure
[...]
configure: creating ./config.status
config.status: creating config.make
config.status: creating config.hh
config.status: config.hh is unchanged
 $ make
 *** /code/LilyPond/build/config.hh is out of date
 *** Remove it and rerun autogen:
         rm /code/LilyPond/build/config.hh; ./autogen.sh
 $ make clean
[...]
 $ make
 *** /code/LilyPond/build/config.hh is out of date
 *** Remove it and rerun autogen:
         rm /code/LilyPond/build/config.hh; ./autogen.sh

As you can see, configure is "clever" and notices that config.hh would
not change. So instead of touching it (and forcing a full rebuild), it
just keeps the old modification date and our /GNUmakefile.in gets
pretty angry about it.
If I actually remove config.hh and then re-run configure, it obviously
works - but I'd consider this a problem in the build system. Also note
how the recommendation is wrong in my example as I build in a separate
directory...

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Han-Wen Nienhuys-3
In reply to this post by David Kastrup
On Wed, Feb 19, 2020 at 12:51 AM David Kastrup <[hidden email]> wrote:

>
> >> Can you provide me with some recipe to reproduce the problem? Can you
> tell
> >> me what distribution you use? I could use Docker to recreate your setup.
> >
> > Just current Ubuntu eoan.
>
> The following patch makes the commit you pushed compile:
>
> diff --git a/lily/pango-font.cc b/lily/pango-font.cc
> index 8eece690c8..587ed3d4f3 100644
> --- a/lily/pango-font.cc
> +++ b/lily/pango-font.cc
> @@ -17,6 +17,10 @@
>    along with LilyPond.  If not, see <http://www.gnu.org/licenses/>.
>  */
>
> +// Necessary for supporting pango_context_new() and
> +// pango_context_set_font_map() in Pango < 1.22
> +#define PANGO_ENABLE_BACKEND
> +
>

aha.

this looks like fallout from

commit d21ea13a22b1cab8c9cb604aa3fcd2ca8073befd
Author: Matthias Clasen <[hidden email]>
Date:   Thu Jul 4 20:36:00 2019 +0000

    Header cleanup

    Abolish the PANGO_ENABLE_BACKEND and PANGO_ENABLE_ENGINE
    defines. All backend-only apis are moved into private
    headers, all apis that were engine-only are marked as
    deprecated, since engines are.

which is

 $ git describe --contains d21ea13a22b1cab8c9cb604aa3fcd2ca8073befd
1.44~145^2

$ rpm -q pango
pango-1.44.7-1.fc31.x86_64

since you have 1.42 , that seems like the root cause.

I'm preparing a docker image for my lilypond-ci scripts that lets me check
for this case too.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Lukas-Fabian Moser
In reply to this post by David Kastrup
Le mer. 19 févr. 2020 à 09:08, David Kastrup <[hidden email]> a écrit :

Color me curious: why would you try building staging?  The whole point
> of the staging system was to avoid breakage for developers.  Only patchy
> processes are supposed to care about staging.
>

Master didn't compile, and I tried staging next. But I see now that this
doesn't make much sense as staging is more likely to break.

I don't remember what exactly kept Master from compiling yesterday - when I
tried later it worked. But anyway, my stupid procedure enabled me to
confirm that Staging broke with the same error that you encountered.

By the way: does it make sense to compile and use the stable/2.20 branch
for my everyday work (beta testing, so to speak)?

Lukas

>
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> writes:

> Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>>
>> The procedure for a patch would be
>>
>> git apply --index xxxx.diff
>> ./autogen.sh --noconf
>> cd build
>> ../configure --enable-checking  # and/or other desired options
>> make clean test-clean doc-clean
>> CPU_COUNT=9 make -j9 # or whatever other options
>> CPU_COUNT=9 make -j9 check
>> CPU_COUNT=9 make -j9 doc
>
> In my experience this doesn't work in all cases. I just switched back
> from branch where I worked on the build system and here's what I get
> (after running $ autoconf in the src directory):
>  $ ../src/configure
> [...]
> configure: creating ./config.status
> config.status: creating config.make
> config.status: creating config.hh
> config.status: config.hh is unchanged
>  $ make
>  *** /code/LilyPond/build/config.hh is out of date
>  *** Remove it and rerun autogen:
>          rm /code/LilyPond/build/config.hh; ./autogen.sh
>  $ make clean
> [...]
>  $ make
>  *** /code/LilyPond/build/config.hh is out of date
>  *** Remove it and rerun autogen:
>          rm /code/LilyPond/build/config.hh; ./autogen.sh
>
> As you can see, configure is "clever" and notices that config.hh would
> not change. So instead of touching it (and forcing a full rebuild), it
> just keeps the old modification date and our /GNUmakefile.in gets
> pretty angry about it.

"Angry" seems like a weird characterization.

> If I actually remove config.hh and then re-run configure, it obviously
> works - but I'd consider this a problem in the build system. Also note
> how the recommendation is wrong in my example as I build in a separate
> directory...

If config.hh is "outdated", why not run ./config.status --recheck ?  Can
we do that?  We'd probably need to call make recursively then so that it
rereads the regenerated Makefile .

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
In reply to this post by Lukas-Fabian Moser
Lukas-Fabian Moser <[hidden email]> writes:

> Le mer. 19 févr. 2020 à 09:08, David Kastrup <[hidden email]> a écrit :
>
> Color me curious: why would you try building staging?  The whole point
>> of the staging system was to avoid breakage for developers.  Only patchy
>> processes are supposed to care about staging.
>>
>
> Master didn't compile, and I tried staging next. But I see now that this
> doesn't make much sense as staging is more likely to break.
>
> I don't remember what exactly kept Master from compiling yesterday - when I
> tried later it worked. But anyway, my stupid procedure enabled me to
> confirm that Staging broke with the same error that you encountered.
>
> By the way: does it make sense to compile and use the stable/2.20 branch
> for my everyday work (beta testing, so to speak)?

That would certainly make sense as long as it has what you need.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Jonas Hahnfeld
In reply to this post by David Kastrup
Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup:

> Jonas Hahnfeld <
> [hidden email]
> > writes:
>
> > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
> > > The procedure for a patch would be
> > >
> > > git apply --index xxxx.diff
> > > ./autogen.sh --noconf
> > > cd build
> > > ../configure --enable-checking  # and/or other desired options
> > > make clean test-clean doc-clean
> > > CPU_COUNT=9 make -j9 # or whatever other options
> > > CPU_COUNT=9 make -j9 check
> > > CPU_COUNT=9 make -j9 doc
> >
> > In my experience this doesn't work in all cases. I just switched back
> > from branch where I worked on the build system and here's what I get
> > (after running $ autoconf in the src directory):
> >  $ ../src/configure
> > [...]
> > configure: creating ./config.status
> > config.status: creating config.make
> > config.status: creating config.hh
> > config.status: config.hh is unchanged
> >  $ make
> >  *** /code/LilyPond/build/config.hh is out of date
> >  *** Remove it and rerun autogen:
> >          rm /code/LilyPond/build/config.hh; ./autogen.sh
> >  $ make clean
> > [...]
> >  $ make
> >  *** /code/LilyPond/build/config.hh is out of date
> >  *** Remove it and rerun autogen:
> >          rm /code/LilyPond/build/config.hh; ./autogen.sh
> >
> > As you can see, configure is "clever" and notices that config.hh would
> > not change. So instead of touching it (and forcing a full rebuild), it
> > just keeps the old modification date and our /GNUmakefile.in gets
> > pretty angry about it.
>
> "Angry" seems like a weird characterization.
>
> > If I actually remove config.hh and then re-run configure, it obviously
> > works - but I'd consider this a problem in the build system. Also note
> > how the recommendation is wrong in my example as I build in a separate
> > directory...
>
> If config.hh is "outdated", why not run ./config.status --recheck ?  Can
> we do that?  We'd probably need to call make recursively then so that it
> rereads the regenerated Makefile .
If I understand the situation correctly, ./config.status --recheck
wouldn't touch config.hh either, right? So the dependency isn't
correctly satisfied and we would always run it from then on,
effectively slowing down our build system.
And that is why I don't want to deal with this kind of issues - this
should come with the build system for free.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> [hidden email]
>> > writes:
>>
>> > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>> > > The procedure for a patch would be
>> > >
>> > > git apply --index xxxx.diff
>> > > ./autogen.sh --noconf
>> > > cd build
>> > > ../configure --enable-checking  # and/or other desired options
>> > > make clean test-clean doc-clean
>> > > CPU_COUNT=9 make -j9 # or whatever other options
>> > > CPU_COUNT=9 make -j9 check
>> > > CPU_COUNT=9 make -j9 doc
>> >
>> > In my experience this doesn't work in all cases. I just switched back
>> > from branch where I worked on the build system and here's what I get
>> > (after running $ autoconf in the src directory):
>> >  $ ../src/configure
>> > [...]
>> > configure: creating ./config.status
>> > config.status: creating config.make
>> > config.status: creating config.hh
>> > config.status: config.hh is unchanged
>> >  $ make
>> >  *** /code/LilyPond/build/config.hh is out of date
>> >  *** Remove it and rerun autogen:
>> >          rm /code/LilyPond/build/config.hh; ./autogen.sh
>> >  $ make clean
>> > [...]
>> >  $ make
>> >  *** /code/LilyPond/build/config.hh is out of date
>> >  *** Remove it and rerun autogen:
>> >          rm /code/LilyPond/build/config.hh; ./autogen.sh
>> >
>> > As you can see, configure is "clever" and notices that config.hh would
>> > not change. So instead of touching it (and forcing a full rebuild), it
>> > just keeps the old modification date and our /GNUmakefile.in gets
>> > pretty angry about it.
>>
>> "Angry" seems like a weird characterization.
>>
>> > If I actually remove config.hh and then re-run configure, it obviously
>> > works - but I'd consider this a problem in the build system. Also note
>> > how the recommendation is wrong in my example as I build in a separate
>> > directory...
>>
>> If config.hh is "outdated", why not run ./config.status --recheck ?  Can
>> we do that?  We'd probably need to call make recursively then so that it
>> rereads the regenerated Makefile .
>
> If I understand the situation correctly, ./config.status --recheck
> wouldn't touch config.hh either, right?

But after running it we should be fine touching it ourselves.

./config.status --recheck && touch config.hh && $(MAKE) all

Add directory variables as needed.

> So the dependency isn't correctly satisfied and we would always run it
> from then on, effectively slowing down our build system.  And that is
> why I don't want to deal with this kind of issues - this should come
> with the build system for free.

Well, since we have our own build system, making it come for free is
sort of our own job.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Han-Wen Nienhuys-3
On Wed, Feb 19, 2020 at 10:03 AM David Kastrup <[hidden email]> wrote:

>
> > So the dependency isn't correctly satisfied and we would always run it
> > from then on, effectively slowing down our build system.  And that is
> > why I don't want to deal with this kind of issues - this should come
> > with the build system for free.
>
> Well, since we have our own build system, making it come for free is
> sort of our own job.
>
>
I think it's easier if we give up on intelligence here, and just recommend
ccache. I think ccache uses content checksums, so even if the file is
touched, it can get the compilation result from cache if it was seen before.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
12