On master (7ae86b3c6845873ca96650fc69beb4ae5285c801) installed Homebrew sqlite
package is ignored during build on macOS.
This PR fixes this issue and update macOS build docs.
Closes #20498.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Tested 0479464ac938b3d51f7f38b19a20ed2a5dcf9c60 on macOS 11.0.1 with Homebrew 2.6.0
Verified that homebrews sqlite
is auto-selected after installation and builds sucessfully.
Interestingly, after uninstalling brews sqlite
I still found references to ghost homebrew libraries in the Makefile because of the way brew --prefix sqlite3
works: https://github.com/Homebrew/brew/blob/3821d37997a7b385cc97bb51169de56f641d5c39/Library/Homebrew/cmd/--prefix.rb#L23
It means that if brew
is installed but brew’s sqlite
is not, then brew --prefix sqlite
will still return where it would install it, and having this path added to the Makefile accordingly.
I have tested that installation does indeed still pass in this case, but it might still be worth testing the sqlite prefix and then the presence of the binary/bin folder itself to avoid a future issue, e.g.:
test ! -d $(brew --prefix sqlite)/bin
18@@ -19,7 +19,7 @@ Then install [Homebrew](https://brew.sh).
19
20 ## Dependencies
21 ```shell
22-brew install automake berkeley-db4 libtool boost miniupnpc pkg-config python qt libevent qrencode sqlite
23+brew install automake libtool boost miniupnpc pkg-config python qt libevent qrencode
24 ```
25
26 If you run into issues, check [Homebrew's troubleshooting page](https://docs.brew.sh/Troubleshooting).
It means that if
brew
is installed but brew’ssqlite
is not, thenbrew --prefix sqlite
will still return where it would install it, and having this path added to the Makefile accordingly.
I think the code in this PR handles this case fine, as it actually adds a non-existent path to the PKG_CONFIG_PATH
, that in turn effectively is noop, right?
It means that if
brew
is installed but brew’ssqlite
is not, thenbrew --prefix sqlite
will still return where it would install it, and having this path added to the Makefile accordingly.I think the code in this PR handles this case fine, as it actually adds a non-existent path to the
PKG_CONFIG_PATH
, that in turn effectively is noop, right?
I’m not that experienced with Makefiles’ path interpreter but agree that having that extra (non-existant) path in PKG_CONFIG_PATH
did not seem to affect the build in any way when brews sqlite3
was not installed.
Updated 0479464ac938b3d51f7f38b19a20ed2a5dcf9c60 -> 7bf449ee5c4fb0748370981f1205c356162e58b4 (pr20527.02 -> pr20527.03, diff):
It might be helpful to add a general note here that wallet support requires one or both of the dependencies in the sections below.
This change unifies Homebrew packages workflow, and does not change
behavior.
Updated 7bf449ee5c4fb0748370981f1205c356162e58b4 -> 03c65e4f704c4baa9bd72a56e8afdb92ec5d4d33 (pr20527.03 -> pr20527.04):
tACK 03c65e4f704c4baa9bd72a56e8afdb92ec5d4d33
Building without brew sqlite3
(but with brew installed) now leaves no trace in config.log:
0SQLITE_CFLAGS=''
1SQLITE_LIBS='-lsqlite3'
vs building with brew sqlite3
:
0SQLITE_CFLAGS='-I/usr/local/Cellar/sqlite/3.33.0/include'
1SQLITE_LIBS='-L/usr/local/Cellar/sqlite/3.33.0/lib -lsqlite3'
651 fi
652- if test x$qt5_prefix != x; then
653- PKG_CONFIG_PATH="$qt5_prefix/lib/pkgconfig:$PKG_CONFIG_PATH"
654- export PKG_CONFIG_PATH
655+
656+ if $BREW list --versions sqlite3 >/dev/null; then
Shouldn’t this, in principle, be conditional on sqlite3 support actually being requested? (like the use_bdb
above, and same for qt5
below)
I’m sure it works but I think it leaves some scope for unexpected differences in behavbior if the build configuration unconditionally depends on the system instead of what the user asks.
Updated 03c65e4f704c4baa9bd72a56e8afdb92ec5d4d33 -> c932e0d67e4b369e4265267da6c8bebac2b6fb53 (pr20527.04 -> pr20527.05, diff):
Shouldn’t this, in principle, be conditional on sqlite3 support actually being requested? (like the
use_bdb
above, and same forqt5
below)I’m sure it works but I think it leaves some scope for unexpected differences in behavbior if the build configuration unconditionally depends on the system instead of what the user asks.
use_bdb
checkWith brew sqlite installed, running ./configure --with-sqlite=no
I still see a single artefact of sqlite in config.log:
05390:PKG_CONFIG_PATH='/usr/local/opt/qt/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:
It does not appear to impact the build, but I am curious how it’s ending up there, as the code would suggest this would only be prepended to PKG_CONFIG_PATH when if test "x$use_sqlite" != xno && $BREW list --versions sqlite3 >/dev/null
is satisfied?
That said, another tACK of c932e0d67e4b369e4265267da6c8bebac2b6fb53
With brew sqlite installed, running
./configure --with-sqlite=no
I still see a single artefact of sqlite in config.log:05390:PKG_CONFIG_PATH='/usr/local/opt/qt/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:
It does not appear to impact the build, but I am curious how it’s ending up there, as the code would suggest this would only be prepended to PKG_CONFIG_PATH when
if test "x$use_sqlite" != xno && $BREW list --versions sqlite3 >/dev/null
is satisfied?That said, another tACK of c932e0d
Hmm, did you run ./autogen.sh
before ./configure
?
With brew sqlite installed, running
./configure --with-sqlite=no
I still see a single artefact of sqlite in config.log:05390:PKG_CONFIG_PATH='/usr/local/opt/qt/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:
It does not appear to impact the build, but I am curious how it’s ending up there, as the code would suggest this would only be prepended to PKG_CONFIG_PATH when
if test "x$use_sqlite" != xno && $BREW list --versions sqlite3 >/dev/null
is satisfied? That said, another tACK of c932e0dHmm, did you run
./autogen.sh
before./configure
? @hebasto you are right, re-runningautogen.sh
sorted it!