Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Freitag, den 13.03.2020, 23:09 -0600 schrieb Anthony Fok:
>> On Fri, Mar 13, 2020 at 2:02 AM Jonas Hahnfeld <
>> address@hidden
>> > wrote:
>> > I'm still not convinced that we need compatibility code, but I'm happy
>> > with anything that gets us to a release and is not technically wrong.
>> 
>> By the way, from a Debian package maintainer point of view, breaking
>> backward compatibility is OK as long as it is documented, so if
>> breaking backward compatibility makes the code cleaner, more correct,
>> and/or easier to maintain for the future, I'd say "please break
>> compatibility"!
>
> I definitely think that's the case here.

Backward compatibility will always get retired eventually.  For the
current decision the main target is not really distributions since those
tend not to package unstable versions anyway.

>> But of course, if that's the case, please document the change in
>> INSTALL.txt or something like that, and say something like "Warning
>> (especially for packagers): New instructions for building, different
>> from 2.20.0!  Please read INSTALL.txt" in the release notice on
>> http://lilypond.org/news.html would be quite sufficient.  ;-)
>
> And I fully agree here. My first patch from last weekend showed an
> error: "Non-empty GUILE_CONFIG detected, support has been removed.
> The new interface uses pkg-config. Please check that configure finds
> the right version. If needed, set PKG_CONFIG_PATH and
> PKG_CONFIG_LIBDIR."
>
> For documentation in INSTALL.txt, I'd propose to replace
> "Use version 1.8.8. Version 2.x of Guile is not currently supported."
> with 
> "Use version 1.8.8 and set PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR for
> configure to find it. Version 2.x of Guile will be fully supported in
> the future and is already used if no other installation is found."
>
> Would that meet your expectations?

The INSTALL.txt text should reflect the current situation, not future
ones.  So it is more like

    libguile 2.x is getting used if no installation of 1.8.8 is found
    during configuration.  However, matching the reliability and
    performance of LilyPond when using libguile 1.8.8 is ongoing work,
    so it is still recommended to compile LilyPond using libguile 1.8.8
    for now.

I would expect that once we find Guilev2 based compilations to be as
dependable and performant as libguile 1.8.8, support for 1.8.8 would be
on the chopping block fast enough that rewriting that paragraph again
rather than removing it would not be necessary.

-- 
David Kastrup