Jonas Hahnfeld <[email protected]> writes: > Am Sonntag, den 08.03.2020, 12:34 +0100 schrieb David Kastrup: >> Jonas Hahnfeld < >> [email protected] >> > writes: >> >> > Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup: >> > > Han-Wen Nienhuys < >> > > [email protected] >> > > >> > > > writes: >> > > > > What about "an error would be a nuisance when trying to have a common >> > > > > configuration for both 2.20 and 2.21" was unclear? >> > >> > There will never be a shared configuration for both 2.20 and 2.21: >> > Current master requires Python 3 which 2.20 not even attempts to be >> > compatible with. >> >> Many systems install both Python2 and Python3 and the respective >> configure scripts are perfectly fine finding and using the required >> version. I wasn't trying to imply that we can share the _results_ of >> running configure, but a common starting position, given the autoprobing >> nature of autoconf, is a lot more realistic. > > My point is that setting the PYTHON variable is equally broken.
Can we argue actual problems rather than strawmen? There has never been a requirement to set the PYTHON variable for compiling LilyPond. >> That basically amounts to "we can figure it out, so everybody else >> should". I don't doubt your competency, but it just isn't >> representative for everyone wanting to use/compile/support LilyPond. > > No, it amounts to "it works the same as it does for other packages". Other packages don't play the role Guile-1.8 does with LilyPond, for better or worse. That is the principal stumbling block for compiling LilyPond on a current system. >> It isn't, for example, representative for the people typically doing >> git bisection in order to find out where something went wrong. Hard >> cutoff points in working configurations make something like bisection >> a lot more painful. > > Not being able to change gradually makes development more painful. You are not talking about gradual change. You are talking about hard change. _I_ am talking about gradual change which you consider unacceptable. > There was discussion as to why there are so few developers - this will > be my prime reason if I'm required to add compatibility for > everything. Yes, this includes things so fundamental as Guile. Again, can we stop arguing strawmen? I am talking about Guile (or more exactly, libguile) while you continue to insist talking about "everything". Also as far as I can tell, you consider the current situation without any documented way of getting a custom Guile-1.8 compilation to compile fine. Because it is the same as getting some old Freetype library to compile. For LilyPond, those are not problems of equivalent prevalence. I do not want to imply that it is a good thing that we don't document how to supplant _any_ system-provided library using pkg-config, but the consequences for the project are quite worse in respect to libguile than for libfreetype. -- 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".
