> On Nov 8, 2022, at 1:03 AM, Jim DeLaHunt <list+gnuc...@jdlh.com> wrote:
>
> On 2022-11-06 16:17, John Ralls wrote:
>
>>
>>> On Nov 6, 2022, at 1:33 PM, Jim DeLaHunt <list+gnuc...@jdlh.com> wrote:
>>>
>>> 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.
>> No, harfbuzz-no-cairo fails to build because the rebuild of
>> freetype-no-harfbuzz *didn't* succeed in removing its dependency on brotli.
>> That's what
>>
>>> pkg-config error with 'freetype2': Could not generate cargs for freetype2:
>>> Package libbrotlidec was not found in the pkg-config search path.
>>> Perhaps you should add the directory containing `libbrotlidec.pc'
>>> to the PKG_CONFIG_PATH environment variable
>>> Package 'libbrotlidec', required by 'freetype2', not found
>>>
>> is telling you. One possibility is that the install step didn't replace
>> /Users/gtkdeveloper/gnucash/inst/lib/pkgconfig/freetype2.pc, the other is
>> that cmake ignored FT_DISABLE_BROTLI perhaps because
>> BROTLIDEC_INCLUDE_DIRS:PATH and BROTLIDEC_LIBRARIES:FILEPATH are already set
>> in CMakeCache.txt.
>>
>>> 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/* .
>> Sigh. Here's the problem:
>> https://github.com/Kitware/CMake/blob/890d44792307134b41274b52cd972e4944af7d36/Modules/Platform/Darwin.cmake#L265
>>
>> It might be possible to disable that with
>> https://cmake.org/cmake/help/latest/variable/CMAKE_IGNORE_PREFIX_PATH.html#variable:CMAKE_IGNORE_PREFIX_PATH
>> to '/opt/local' or
>> https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_USE_CMAKE_SYSTEM_PATH.html#variable:CMAKE_FIND_USE_CMAKE_SYSTEM_PATH
>> too 'NO'. E.g., add to jhbuildrc-custom
>> cmakeargs = "-DCMAKE_IGNORE_PREFIX_PATH=/opt/local", but meson also uses
>> cmake to find stuff and it's not clear from the meson docs whether one can
>> add the same thing to its cmake_args; I guess that would look like
>> mesonargs = "-Dcmake_args=-DCMAKE_IGNORE_PREFIX_PATH=/opt/local".
>>
>>> 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>.
>>>
>> gtkosxapplication is what puts the menus on the menu bar instead of on the
>> window. If you want to build without it you need to hide
>> $PREFIX/lib/pkgconfig/gtk-mac-integration-gtk3.pc.
>>
>> But that crash hasn't anything to do with gtkosxapplication. I think it's
>>
>> Try applying
>> https://gitlab.gnome.org/GNOME/gtk-osx/-/blob/master/patches/gtk-3.24.33-quartz-window-transient-for.patch
>> to your gtk3-24.34 build.
>>
>> The fix in gtk itself is
>> https://gitlab.gnome.org/GNOME/gtk/-/commit/a2c54c739ed08eac6d360cd3a6ae140e1fab556d
>> but that does a bunch of other stuff too. I committed it after Mattias
>> released 3.23.34.
>
> Thank you for this helpful information, John.
>
> I have not had a chance to try it out yet, but I will later this week. I will
> reply with what I find out.
That would be off-topic for here, so better to use
https://github.com/jralls/gtk-osx-build/discussions.
https://discourse.gnome.org would be arguably more appropriate still, but
you'll have to tell me that you started a discussion there, the notifications
don't work and I don't visit regularly.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
