Hello friends,
> Le 18 août 2022 à 09:16, Jacques Menu <imj-muz...@bluewin.ch> a écrit : > I’ve never heard about Xcode_11.3.1.xip. > The simple way to install Xcode is to take it from the App Store (needs about > 50 Mb these days). That's what I was thinking of doing, but on the app store you can only find the version compatible with the latest Mac OS (Monterey) and it requires a dozen Mb. Being on Mojave (10.14) it was necessary to find on the Apple site the version which goes well https://developer.apple.com/download/all/. There Xcode is 7.82 Gb and takes very very long to install. Installing the MacOSX10.14.sdk file is endless too. too. Finally the "standalone" applications are not so bad > >> Le 18 août 2022 à 08:48, Jean-Julien Fleck <jeanjulien.fl...@gmail.com> a >> écrit : >> >> I have a question about the installation. Could this erratic behavior be a >> result of this .sdk file being installed in the wrong order? is it possible >> to uninstall Frescobaldi using some magic formula like "sudo port uninstall >> frescobaldi" and do an install again so that the installer finds the sdk >> file. Especially will there be a difference. Just an idea... >> >> Well, it’s unlikely. I happen to have frescobaldi installed via a fresh new >> MacPort procedure (after upgrading to MacOs Monterey) just last week and the >> missing sdk message I encountered was related to all the qt5 stuff that >> frescobaldi needed in order to be built. You were lucky it was not a stopper >> as it was in my case: I had to manually add `use_xcode yes` There, I would not have been able to add this kind of comment >> in the corresponding PortFile of py310-poppler-qt5 in order to make it build >> properly. Perhaps it has since been corrected so that if the «standard» way >> for qt5 to find the sdk won't work, they try the `use_xcode yes` trick >> (whatever it does) before giving up. Everything around qt5 seems to be a weak point of Frescobaldi, since it was also this qt bug that was preventing Frescobaldi 3.1 from installing on my Mac. >> >> All these problems, even if triggered during frescobaldi install, are >> unrelated to it. That's just the way Macport is doing the job: whenever you >> add a package to MacPort, it asks you what should be present on the machine >> to make your app work and then try to install it by itself, saving the user >> the trouble to install all the extensions and preventing multiple installs >> of the same tools whenever two different packages need the same first >> building block. >> >> But as a matter of fact, it won't help to uninstall frescobaldi to try to >> correct for lilypond path (as for one reason is that MacPort don't throw >> away uninstalled port but keep them somewhere, ready to reinstall it without >> further building in case you change your mind). I would rather suspect that >> the search for different lilypond locations was done after you first looked >> there (perhaps triggered by one of your tinkering), was written down >> somewhere so that the next frescobaldi startup shows it. This answers my question exactly, even though I suspected it a bit. >> >> Happy that you finally managed to get it work and have fun coding with lily >> on frescobaldi ! With a good bit of luck, Thank you >>