Jonas Hahnfeld <[email protected]> writes: > Am Sonntag, den 08.03.2020, 15:04 +0100 schrieb David Kastrup: >> Jonas Hahnfeld < >> [email protected] >> > writes: >> >> > How about the attached change? This attempts to locate the .pc file >> > next to guile-config and tries to be very transparent about this. If it >> > finds a directory, it restricts pkg-config to look only there. This >> > should work with non-default installations of Guile, at least it works >> > for a test setup on my machine. >> >> Ok, I am obviously missing something important here. You go to a lot of >> pain to use pkgconfig when someone specifies guile-config. > > Right, I should have done a better job explaining the rationale > here. I agree that just setting GUILE_CFLAGS and GUILE_LIBS based on > guile- config will likely work, for now. > > However as Werner described yesterday, we might want to modularize our > aclocal.m4. As part of that, we'll likely end up using the official > guile.m4 which relies on pkg-config.
Correct me if I am wrong, but the "official" *.m4 files basically implement tests. The framework calling and interpreting those tests is basically in configure.in and quite up to us. In addition, any non-standard tests could be done locally by us, probably mostly relying on the standard tests but augmenting them. So I am reasonably confident that with some reasonably designed chunks of code, we'd end up with comparatively small headaches in upkeep. My own gut feeling is that we'd not burn (or obstruct) any major bridges supporting GUILE_CONFIG: if it is explicitly given, we don't really need to check for versions or any other viability considerations: we can just set the variables and be done. That's small enough that I would not have qualms putting it in configure.in . > Now we can of course try to re- implement all functionality from there > using guile-config. But that's a major distraction and exactly what > I'm fearing contributors working on the build system will have to do. I can assure you of two things: a) I would not consider that a reasonable thing to do. b) I don't call the shots. We still work on a base of loose consensus here. I may seem to carry a lot of weight, but that's mainly because I am thick-headed and persistent, and because I tend to make sense. And while I am thick-headed, I am not an idiot (I realise that a lot of people will disagree with that assessment, but it's probably easier to humour me on that one). So if you base your decision-making now on the persuasion that I will not try adapting the kind of decisions and opinions formed now to future situations, I think you are making life harder for everyone involved than strictly called for. > Again, sorry for not spelling out all this from the very beginning; I > just don't have a clear understanding yet how these things will work > out at the end. What I want to avoid, and that's why I have been (and > still am) imposed to this type of compatibility, is that legacy things > get into our (my) way of modernizing the build system. That's a good reason for keeping things modular, and for rethinking decisions when circumstances change. Which also is aided by keeping things modular, namely making sure that the consequences of isolated strategic decisions are not littered all over the place but kept in identifiable stretches of code. > It already is a mess (speak up if you disagree It's almost insulting to even contemplate my disagreement. There is comparatively little in my work on LilyPond that doesn't fit the characterisation of making things less messy in programming, solving problems, using and working with LilyPond. And I have had very little contact to LilyPond's build system. One reason I am completely out of my depth when trying to tackle something like <https://sourceforge.net/p/testlilyissues/issues/5822/> where I loosely bolt on stuff on existing procedures and (mostly futilely) beg people to check that some of my bolts are somewhat in the right place. And ask them to tell me where else they should get fitted. > and I'll happily point you to places that I already cleaned up or that > still need IMO). Working on it is complicated enough, even without > having to do archaeological research on what used to work in the past > and how to make new things work in old environments. > > That said, I also want 2.21.0 to happen soon - I was hoping we could do > it this weekend. Now we have a blocker, introduced by a change more > than a week ago. And it's in the build system, something that I > absolutely wanted to avoid this last week for non-trivial cleanups as > to not break GUB again. > Do you understand the dilemma I'm facing? Sure. I was not in the position where I could have told people authoritively (and "authoritively" I never am) to stop doing major work on master. And I would want to avoid the situation where we have to release unstable releases (even something like 2.21.0) from a curated branch rather than master. The time plan of 2.20 and 2.21 was reasonably clear (even if somewhat optimistic) after Salzburg, so I relied on a mixture of luck and appeal to responsibility and insight for making stuff work out. It would have been nice to either not have to deal with large changes of build infrastructure, or to be progressed enough with it that one could confidently cater for special cases. That's not in every respect how things turned out, and I would not want to have it otherwise, either: I am glad we made the progress we did. Nevertheless, we want to find a minimally invasive solution that will tend to "just work" without major modification for people without having to change in the user/compiler related respects a whole lot in short course. I think a safe step right now is for Werner to update the upstream pkgconfig autoconf support. Whatever we end up with, there is no point in designing a solution that does not involve that as a component. I wanted to suggest him fast-tracking that change separately because of that. -- 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".
