Jonas Hahnfeld <hah...@hahnjo.de> writes: > Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup: >> David Kastrup < >> d...@gnu.org >> > writes: >> >> > If I previously did >> > >> > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure >> > ./config.status --recheck >> > >> > then the Guile configuration was reused. If I now do >> > >> > PKG_CONFIG_PATH=/usr/local/tmp/guile-1.8/lib/pkgconfig ./configure >> > ./config.status --recheck >> > >> > the configuration information is lost and configure reverts to the >> > system configuration. >> > >> > In addition, PKG_CONFIG_PATH is not documented in our configuration or >> > with ./configure --help. >> > >> > How to fix? >> > >> > A documented option --with-guile-prefix or --with-libguile-prefix that >> > puts up a working configuration might be a reasonably transparent and >> > future-safe option. >> > >> > Also now I don't think it made sense to _remove_ the GUILE_CONFIG >> > variable: if it's set, it seems worth heeding. If it's unset, going via >> > pkgconfig may be the right way. --with-libguile-prefix could pick the >> > right option underneath, checking that it is viable, and prefer using >> > PKG_CONFIG_PATH . >> >> To put this into perspective: this definitely is a showstopper for >> 2.21.0. A quick fix would be reverting the whole patch for issue 5780 >> in order to get back to a compatible state to what we had previously. A >> minimum fix would be recovering use of GUILE_CONFIG (when it is being >> specified) in order to get back to the previous state of usability. >> Given that I had several segfaults with GUILE-2.2 in recent days, I also >> strongly lean towards continuing to require --enable-guile2 for getting >> Guile2+. We can reword the "highly experimental" bit. >> >> At any rate, INSTALL.txt does not reflect _any_ of these changes. It >> states >> >> • Guile ( >> http://www.gnu.org/software/guile/guile.html >> ) Use version >> 1.8.8. Version 2.x of Guile is not currently supported. > > I disagree that it's a showstopper for 2.21.0: It's different than > before, true, but it works (if you know how to do it).
"It works if you know how to do it" is elitist talk. It's not release-ready when there is no documented way of doing it. > Why should we keep honoring environment variables in the configure > process just for the sake of compatibility? For the sake of compatibility. We can complain. We can even output a message what to do instead and abort with an error. In my book, that's something for the next stage of deprecation, but we can discuss that. But silently pretending that an option never existed while not documenting alternatives: that's not "for the sake of compatibility" we are talking about here but rather "for the sake of anybody still foolish enough to want to compile LilyPond". > guile-config has been deprecated by upstream in favor of pkg-config, > so I think it makes sense to move on. So? guile-config has been _deprecated_ since at least version 1.8. And version 3.0 still has it. What does this tell you about how others do deprecation? There is absolutely nothing wrong with "moving on" to the recommended way of doing things. What is wrong is doing this silently, telling nobody, and leaving people out in the rain. > The documentation can certainly be improved, and I think it has been > requested in the review (this already the second or third time that > this gets lost in our process). But after all, this is supposed to be > an unstable release and serve as a reference point for future > development, right? A reference point that nobody manages to compile is not worth much. With regard to documentation (in particular translations) and functionality being at somewhat of a discord for unstable releases, that is something to expect for user-level features. Also that features/behavior might not persist but get paddled back. And of course, that crashes occur. But not being able to compile because of silent undocumented changes in the configure process? That makes a release pretty pointless. Getting things to compile is sort of a prerequisite of evaluating a release. -- David Kastrup
