[GNC-dev] Various failures while building MacOS/Quartz from source

[Jim DeLaHunt]

On 2022-11-06 07:15, john wrote:
> On Nov 5, 2022, at 2:21 AM, Jim DeLaHunt <list+gnucash at jdlh.com> wrote:
>> Thank you. That got me a step further.
>> freetype-no-harfbuzz now compiles happily, but harfbuzz-no-cairo seems to be unhappy about freetype's lack of libbrotlidec in the same way:
>>
>> =====
>>
>> *** Configuring harfbuzz-no-cairo *** [2/2]
>> ...[snip]...
>> ../../src/harfbuzz-4.1.0/meson.build:87:0: ERROR: Dependency 'freetype2' is required but not found.
>>
>> A full log can be found at /Users/gtkdeveloper/gnucash/build/harfbuzz-4.1.0/meson-logs/meson-log.txt
>> meson --prefix /Users/gtkdeveloper/gnucash/inst --libdir lib -Dcoretext=enabled -Dfreetype=enabled -Ddocs=disabled -Dbenchmark=disabled -Dintrospection=disabled --wrap-mode=nofallback /Users/gtkdeveloper/gnucash/src/harfbuzz-4.1.0
>> *** Error during phase configure of harfbuzz-no-cairo: ########## Error running meson --prefix /Users/gtkdeveloper/gnucash/inst --libdir lib -Dcoretext=enabled -Dfreetype=enabled -Ddocs=disabled -Dbenchmark=disabled -Dintrospection=disabled --wrap-mode=nofallback /Users/gtkdeveloper/gnucash/src/harfbuzz-4.1.0 *** [2/2]
>>
>> =====
>> ...[snip]...
>> Like a good script kiddie, I tried adding to jhbuildrc-custom a line:
>>    module_cmakeargs['harfbuzz-no-cairo']="-DFT_DISABLE_BROTLI=YES"
>>
>> ... and cleaning and remaking harfbuzz-no-cairo, but it had no effect.
>>
>> By the way, in the CMake part of the meson-log above, I see a mention of the path /opt/local . It turns out that I do have an /opt/local/lib/libbrotlidec*.dylib and /opt/local/lib/pkgconfig/libbrotlidec.pc,  installed there by MacPorts port "brotli". If Cmake looks for libraries in /opt/local, maybe it found that.
>>
>> Thank you for your help, John. If I may continue to impose, and ideas for a next step?
> Well, to begin with I told you to
>
>>> Add
>>>    module_cmakeargs['freetype']="-DFT_DISABLE_BROTLI=YES"
>>>    module_cmakeargs['freetype-no-harfbuzz']="-DFT_DISABLE_BROTLI=YES"
> and rebuild freetype-no-harfbuzz.

Yes, you did, and I appreciate it. As you will have read above,
 > freetype-no-harfbuzz now compiles happily...

> Rebuilding Harfbuzz isn't going to get rid of Freetype's dependency on brotli. Harfbuz doesn't know anything about broil.

Agreed. Adding the cmakeargs of "-DFT_DISABLE_BROTLI=YES" appeared to 
get rid of Freetype's dependency on brotli, _for the purpose of 
compiling freetype-no-harfbuzz_.

I am moving on to the next problem, which is that harfbuzz-no-cairo 
fails to build, despite the successful fix which enabled Freetype to 
build in a way acceptable freetype-no-harfbuzz. And the symptoms of the 
next problem are interestingly similar to the symptoms of the previous 
problem.

> BTW, you may need to delete CMakeCache.txt from the freetype build directory to get cmake to recognize the new option.

Interesting. I have a lot to learn about CMake. I will try this. Thank you.


> On the other hand, you're likely to have other, more subtle problems with MacPorts libraries contaminating your build. That's why https://wiki.gnome.org/Projects/GTK/OSX/Building#Prerequisites says, in bold italic Mixing HomeBrew, MacPorts, or Fink and GTK-OSX will fail.  If you have created a separate user for jhbuild and it's still finding MacPorts stuff tell me and I'll remove the sentence just before that about creating a separate user; it means that MacPorts metastasizes  more deeply than I thought.

I read that sentence and took it to heart.  You will see a mention of 
/Users/gtkdeveloper in my logs. gtkdeveloper is a macOS user account I 
created specifically to build GnuCash. It does not have any of my 
primary account's path or environment changes. I have not told it about 
MacPorts.

As far I as know, MacPorts installs many files to /opt/local/*, and acts 
like it owns that directory subtree. It installs apps to 
/Applications/MacPorts . Users are responsible for adding /opt/local/bin 
to their own paths. As far as I know from monitoring the project's user 
and developer lists, MacPorts tries to avoid installing anything 
anywhere else.

If there is software on macOS which consults /opt/local/*, then IMHO it 
should be aware it might well find MacPorts-installed software there. If 
it doesn't want to be contaminated by MacPorts, it should have a way to 
refrain from consulting /opt/local/* .

Of course, the difference of opinion between cmake and pkg-config might 
not stem from consulting /opt/local/* .

> One more thing: WebKit doesn't work when built on M1 with macOS 12, it sets the wrong path to its plugins and can't find them. That means that your GnuCash build won't be able to display reports. You can work around that by exporting the report to a file and opening it with your browser of choice.
Yes, I have seen this report.  It might be worse: I tried building 
gnucash 4.11 via the MacPorts `gnucash` port, and a) there is an 
unexpected interaction with gtkosxapplication.h, and b) after hiding 
gtkosxapplication.h, the resulting GnuCash application crashes after 
setting up a new book. I wasn't going to start the thread here about 
those issues until I had got as far as I could with building GnuCash the 
GnuCash way. But there is more on these MacPorts problems at 
<https://trac.macports.org/ticket/66119>.
> Regards,
> John Ralls

I very much appreciate your help. GnuCash is a complex codebase. It is 
marvellous that the core developers can turn out a steady stream of 
reliable releases with the core tools and environments. To also let 
other build that codebase with their own, different tools and 
environments is another level more difficult.