Staging broken.

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

Re: Staging broken.

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

>
>> +// Necessary for supporting pango_context_new() and
>> +// pango_context_set_font_map() in Pango < 1.22
>> +#define PANGO_ENABLE_BACKEND
>> +
>>
>
> ..

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

I did this, see

https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056

it reproduces the failure. I added a fix, and verified it passes on Ubuntu
19.04.

I pushed it to staging.

There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
have time to investigate now.

--
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:

> 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.

That does not seem like much of a help for the problem case at hand.

> 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.

--
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
On Wed, Feb 19, 2020 at 11:06 AM David Kastrup <[hidden email]> wrote:

> Han-Wen Nienhuys <[hidden email]> writes:
>
> > 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.
>
> That does not seem like much of a help for the problem case at hand.


Autoconf tries to leave the config.h alone, using content based checks.

I assume it does this because touching config.h triggers an expensive
global recompile in timestamp-based build systems, like make.

Our GNUmakefile tries to detect changes to config.h.in using timestamps,
but autconf (see above) won't overwrite the file unless it really changed,
so the default doesn't do the right thing.

Our comment says:

# this is to prevent people from getting
# undefined symbols  when we add them to config.h.in,
# and they blindly run "cvs update; make".

the mention of CVS shows you how old this comment is.

My proposal is to have configure always regenerate config.h, because
ccache makes the full rebuild almost free, so we don't need configure's
cleverness.

--
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:

> On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <[hidden email]> wrote:
>
>>
>>> +// Necessary for supporting pango_context_new() and
>>> +// pango_context_set_font_map() in Pango < 1.22
>>> +#define PANGO_ENABLE_BACKEND
>>> +
>>>
>>
>> ..
>
>> I'm preparing a docker image for my lilypond-ci scripts that lets me check
>> for this case too.
>>
>
> I did this, see
>
> https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056
>
> it reproduces the failure. I added a fix, and verified it passes on Ubuntu
> 19.04.
>
> I pushed it to staging.
>
> There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
> have time to investigate now.

Could you explain the urgency warranting an immediate hotfix bypassing
all review, feedback and proper solution-finding?

--
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
In reply to this post by Han-Wen Nienhuys-3
Han-Wen Nienhuys <[hidden email]> writes:

>> > I think it's easier if we give up on intelligence here, and just
>> > recommend ccache.
>>
>> That does not seem like much of a help for the problem case at hand.
>
>
> Autoconf tries to leave the config.h alone, using content based checks.
>
> I assume it does this because touching config.h triggers an expensive
> global recompile in timestamp-based build systems, like make.
>
> Our GNUmakefile tries to detect changes to config.h.in using timestamps,
> but autconf (see above) won't overwrite the file unless it really changed,
> so the default doesn't do the right thing.
>
> Our comment says:
>
> # this is to prevent people from getting
> # undefined symbols  when we add them to config.h.in,
> # and they blindly run "cvs update; make".
>
> the mention of CVS shows you how old this comment is.
>
> My proposal is to have configure always regenerate config.h, because
> ccache makes the full rebuild almost free, so we don't need configure's
> cleverness.

The fix I proposed would be the complicated way to achieve that.
Probably simpler is calling autoconf with the option --force in
autogen.sh.

Maybe that is what we should recommend instead in the Makefile instructions.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

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

> Han-Wen Nienhuys <[hidden email]> writes:
>
>> On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <[hidden email]> wrote:
>>
>>>
>>>> +// Necessary for supporting pango_context_new() and
>>>> +// pango_context_set_font_map() in Pango < 1.22
>>>> +#define PANGO_ENABLE_BACKEND
>>>> +
>>>>
>>>
>>> ..
>>
>>> I'm preparing a docker image for my lilypond-ci scripts that lets me check
>>> for this case too.
>>>
>>
>> I did this, see
>>
>> https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056
>>
>> it reproduces the failure. I added a fix, and verified it passes on Ubuntu
>> 19.04.
>>
>> I pushed it to staging.
>>
>> There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
>> have time to investigate now.
>
> Could you explain the urgency warranting an immediate hotfix bypassing
> all review, feedback and proper solution-finding?

Moved this to dev/pango branch for now so that we have a chance to
discuss this.

--
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.

James Lowe-9
In reply to this post by Jonas Hahnfeld
Hello and sorry I am late to the table on this - been a busy week for me.

On 19/02/2020 08:10, Jonas Hahnfeld wrote:

> 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


Yes this is what I had too (not just recently) and I am sure that I had
some conversation - although I cannot find it on the lists so it must
have been private emails, anyway this was why I haven't been doing 'make
check' but simply applying these 'build file' patches and just running
the gamut of makes minus make check.

If after all these emails there is a better method (at least until we
get the automated build stuff done) I can add this into my workflow.

Thanks and sorry that I didn't think to mention it before more publicly.

James


Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

David Kastrup
[hidden email] writes:

> Hello and sorry I am late to the table on this - been a busy week for me.
>
> On 19/02/2020 08:10, Jonas Hahnfeld wrote:
>> 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
>
>
> Yes this is what I had too (not just recently) and I am sure that I
> had some conversation - although I cannot find it on the lists so it
> must have been private emails, anyway this was why I haven't been
> doing 'make check' but simply applying these 'build file' patches and
> just running the gamut of makes minus make check.
>
> If after all these emails there is a better method (at least until we
> get the automated build stuff done) I can add this into my workflow.
>
> Thanks and sorry that I didn't think to mention it before more publicly.

The simplest way is to follow the given instructions as close as makes
sense (namely, if the given directories are wrong, use the right ones,
and if you were going to run autogen.sh and configure separately and/or
from different directories, do so).

We'll likely come up soonish with something obliterating the problem (or
at least a better diagnosis) but in the mean time and/or older code,
that seems like the best bet.

--
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, 17:30 +0100 schrieb David Kastrup:

> David Kastrup <
> [hidden email]
> > writes:
>
> > Han-Wen Nienhuys <
> > [hidden email]
> > > writes:
> >
> > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <
> > > [hidden email]
> > > > wrote:
> > >
> > > > > +// Necessary for supporting pango_context_new() and
> > > > > +// pango_context_set_font_map() in Pango < 1.22
> > > > > +#define PANGO_ENABLE_BACKEND
> > > > > +
> > > > >
> > > >
> > > > ..
> > > > I'm preparing a docker image for my lilypond-ci scripts that lets me check
> > > > for this case too.
> > > >
> > >
> > > I did this, see
> > >
> > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056
> > >
> > >
> > > it reproduces the failure. I added a fix, and verified it passes on Ubuntu
> > > 19.04.
> > >
> > > I pushed it to staging.
> > >
> > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
> > > have time to investigate now.
> >
> > Could you explain the urgency warranting an immediate hotfix bypassing
> > all review, feedback and proper solution-finding?
>
> Moved this to dev/pango branch for now so that we have a chance to
> discuss this.
For the record, you seem to have pushed to commits to staging -> master
again, right?

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, 17:30 +0100 schrieb David Kastrup:
>> David Kastrup <
>> [hidden email]
>> > writes:
>>
>> > Han-Wen Nienhuys <
>> > [hidden email]
>> > > writes:
>> >
>> > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <
>> > > [hidden email]
>> > > > wrote:
>> > >
>> > > > > +// Necessary for supporting pango_context_new() and
>> > > > > +// pango_context_set_font_map() in Pango < 1.22
>> > > > > +#define PANGO_ENABLE_BACKEND
>> > > > > +
>> > > > >
>> > > >
>> > > > ..
>> > > > I'm preparing a docker image for my lilypond-ci scripts that lets me check
>> > > > for this case too.
>> > > >
>> > >
>> > > I did this, see
>> > >
>> > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056
>> > >
>> > >
>> > > it reproduces the failure. I added a fix, and verified it passes on Ubuntu
>> > > 19.04.
>> > >
>> > > I pushed it to staging.
>> > >
>> > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
>> > > have time to investigate now.
>> >
>> > Could you explain the urgency warranting an immediate hotfix bypassing
>> > all review, feedback and proper solution-finding?
>>
>> Moved this to dev/pango branch for now so that we have a chance to
>> discuss this.
>
> For the record, you seem to have pushed to commits to staging -> master
> again, right?

Yes.  Han-Wen and I had an off-list discussion about the impact of the
changes, and they are at least not a regression in respect to the
previous state we had, even if they cannot reduce the number of warnings
in newer versions of Pango to zero while still supporting a range of
older versions.

If anybody can come up with a better/cleaner fix covering the intended
version range, feel free to do so.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Jonas Hahnfeld
Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup:

> Jonas Hahnfeld <
> [hidden email]
> > writes:
>
> > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
> > > David Kastrup <
> > > [hidden email]
> > >
> > > > writes:
> > > > Han-Wen Nienhuys <
> > > > [hidden email]
> > > >
> > > > > writes:
> > > > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <
> > > > > [hidden email]
> > > > >
> > > > > > wrote:
> > > > > > > +// Necessary for supporting pango_context_new() and
> > > > > > > +// pango_context_set_font_map() in Pango < 1.22
> > > > > > > +#define PANGO_ENABLE_BACKEND
> > > > > > > +
> > > > > > >
> > > > > >
> > > > > > ..
> > > > > > I'm preparing a docker image for my lilypond-ci scripts that lets me check
> > > > > > for this case too.
> > > > > >
> > > > >
> > > > > I did this, see
> > > > >
> > > > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056
> > > > >
> > > > >
> > > > >
> > > > > it reproduces the failure. I added a fix, and verified it passes on Ubuntu
> > > > > 19.04.
> > > > >
> > > > > I pushed it to staging.
> > > > >
> > > > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
> > > > > have time to investigate now.
> > > >
> > > > Could you explain the urgency warranting an immediate hotfix bypassing
> > > > all review, feedback and proper solution-finding?
> > >
> > > Moved this to dev/pango branch for now so that we have a chance to
> > > discuss this.
> >
> > For the record, you seem to have pushed to commits to staging -> master
> > again, right?
>
> Yes.  Han-Wen and I had an off-list discussion about the impact of the
> changes, and they are at least not a regression in respect to the
> previous state we had, even if they cannot reduce the number of warnings
> in newer versions of Pango to zero while still supporting a range of
> older versions.
May I ask to have such discussion on-list for the next time? That's why
we have a lilypond-devel, right?

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 Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <[hidden email]> writes:
>>
>> > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
>> > > David Kastrup <
>> > > [hidden email]
>> > >
>> > > Moved this to dev/pango branch for now so that we have a chance to
>> > > discuss this.
>> >
>> > For the record, you seem to have pushed to commits to staging -> master
>> > again, right?
>>
>> Yes.  Han-Wen and I had an off-list discussion about the impact of the
>> changes, and they are at least not a regression in respect to the
>> previous state we had, even if they cannot reduce the number of warnings
>> in newer versions of Pango to zero while still supporting a range of
>> older versions.
>
> May I ask to have such discussion on-list for the next time? That's why
> we have a lilypond-devel, right?

My description of the discussion was not complete.  If it is deemed
important enough, I can try extracting the technically relevant parts of
it, but I am currently trying to at least manage translating the Changes
file into German (for which I've seen no other volunteers) and I'd
prefer to stay away from other emotionally draining tasks until I am
through with that.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Staging broken.

Han-Wen Nienhuys-3
In reply to this post by Jonas Hahnfeld
Here are the relevant parts of a correspondence between me and David.

> > "We have a situation where catering to several versions of Pango has
> > proven tricky to the degree of tripping you up."
> >
> > I think you see this patch as a proof that there is something
> > inherently tricky about working with Pango.
>
> The old interface is deprecated in current version, you want to tackle
> the warnings while the new interface is not available in all versions
> that are supposed to be supported after the patch.
>
> That is not inherently tricky about working with Pango, it means that
> the problem you are trying to tackle with the second one of the patches
> just does not have a good single non-#ifdefed solution within the
> version range you are trying to cover.  That was not obvious from the
> original patch without delving into Pango documentation.

Can you read the patches again, carefully? Neither of the two patches
change any functionality: HAVE_PANGO_FT2 is true since forever. The
RAII patch just moves the same calls to the same deprecated
function to a central place so there are less warnings.

> > I disagree; there is nothing special about this; the only problem is
> > that we need to get feedback of compiling against different Linux
> > distributions before we submit code. By contrast, staring at the code
> > longer, or letting it sit in countdown for more time is not going to
> > help.
>
> An "I am going to just do this; anybody have a better idea?  Otherwise I
> am just going to go ahead." would help avoid the impression that one
> considers other developers and their interests unnecessary baggage.
> It's not formal countdown, will add perhaps half a day to the delay of
> something that nobody knows to be urgent.  And if it is urgent, just
> mentioning the reason while going ahead will at least keep others in the
> loop.
>
> Part of the staging system process is to remove the sense of urgency
> that expresses itself in fixes shot from the hip and tends to get
> tempers higher rather than lower.
>
> [..]
>
> If you feel that it's pointless for anybody to see whether the
> dependencies can be resolved in a manner that appears more tenable for

It's not pointless to improve this, but it's also not mutually
exclusive with going ahead with the current 2 patches, which are
semantic no-op cleanups.

[..]

So, yes, please put these back on staging. If you find it breaks
somewhere somehow, I will come up with a way to fix and test it
quickly.

On Thu, Feb 20, 2020 at 8:28 PM Jonas Hahnfeld <[hidden email]> wrote:

>
> Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup:
> > Jonas Hahnfeld <
> > [hidden email]
> > > writes:
> >
> > > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
> > > > David Kastrup <
> > > > [hidden email]
> > > >
> > > > > writes:
> > > > > Han-Wen Nienhuys <
> > > > > [hidden email]
> > > > >
> > > > > > writes:
> > > > > > On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys <
> > > > > > [hidden email]
> > > > > >
> > > > > > > wrote:
> > > > > > > > +// Necessary for supporting pango_context_new() and
> > > > > > > > +// pango_context_set_font_map() in Pango < 1.22
> > > > > > > > +#define PANGO_ENABLE_BACKEND
> > > > > > > > +
> > > > > > > >
> > > > > > >
> > > > > > > ..
> > > > > > > I'm preparing a docker image for my lilypond-ci scripts that lets me check
> > > > > > > for this case too.
> > > > > > >
> > > > > >
> > > > > > I did this, see
> > > > > >
> > > > > > https://github.com/hanwen/lilypond-ci/commit/145e1e0dcf61c74ff3278ebb1a0fedda17f08056
> > > > > >
> > > > > >
> > > > > >
> > > > > > it reproduces the failure. I added a fix, and verified it passes on Ubuntu
> > > > > > 19.04.
> > > > > >
> > > > > > I pushed it to staging.
> > > > > >
> > > > > > There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
> > > > > > have time to investigate now.
> > > > >
> > > > > Could you explain the urgency warranting an immediate hotfix bypassing
> > > > > all review, feedback and proper solution-finding?
> > > >
> > > > Moved this to dev/pango branch for now so that we have a chance to
> > > > discuss this.
> > >
> > > For the record, you seem to have pushed to commits to staging -> master
> > > again, right?
> >
> > Yes.  Han-Wen and I had an off-list discussion about the impact of the
> > changes, and they are at least not a regression in respect to the
> > previous state we had, even if they cannot reduce the number of warnings
> > in newer versions of Pango to zero while still supporting a range of
> > older versions.
>
> May I ask to have such discussion on-list for the next time? That's why
> we have a lilypond-devel, right?
>
> Jonas



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

Reply | Threaded
Open this post in threaded view
|

How to test 'stepmake' patch (was Re: Staging broken)

James Lowe-7
In reply to this post by David Kastrup
Hello,

On 19/02/2020 19:52, David Kastrup wrote:

> [hidden email] writes:
>
>> Hello and sorry I am late to the table on this - been a busy week for me.
>>
>> On 19/02/2020 08:10, Jonas Hahnfeld wrote:
>>> 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
>>
>> Yes this is what I had too (not just recently) and I am sure that I
>> had some conversation - although I cannot find it on the lists so it
>> must have been private emails, anyway this was why I haven't been
>> doing 'make check' but simply applying these 'build file' patches and
>> just running the gamut of makes minus make check.
>>
>> If after all these emails there is a better method (at least until we
>> get the automated build stuff done) I can add this into my workflow.
>>
>> Thanks and sorry that I didn't think to mention it before more publicly.
> The simplest way is to follow the given instructions as close as makes
> sense (namely, if the given directories are wrong, use the right ones,
> and if you were going to run autogen.sh and configure separately and/or
> from different directories, do so).
>
> We'll likely come up soonish with something obliterating the problem (or
> at least a better diagnosis) but in the mean time and/or older code,
> that seems like the best bet.

See

5783 Use $(MAKE) instead of 'make' in lilypond-book regtests - Han-Wen
Nienhuys
https://sourceforge.net/p/testlilyissues/issues/5783
http://codereview.appspot.com/569400043

I have been using config.status --recheck && touch config.hh method to
test recent 'build' patches and this seems to work without problems
(thanks). However even when I used this method for the above patch I get
a failure while doing the second 'make' (after make test-baseline/apply
patch).

So I have defaulted just to the 'normal'

apply patch to master/configure/make/make test-baseline/make doc workflow

James


12