Re: [was: Re: ANN: Frescobaldi 3.2]

[Jean Louis THIRY]

Hello friends,

> Le 18 août 2022 à 09:16, Jacques Menu <imj-muzhic@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.fleck@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
>>