On 2022-11-06 07:15, john wrote:
On Nov 5, 2022, at 2:21 AM, Jim DeLaHunt <list+gnuc...@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.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
