Skip to content

Conversation

hebasto
Copy link
Member

@hebasto hebasto commented Nov 29, 2020

On master (7ae86b3) installed Homebrew sqlite package is ignored during build on macOS.

This PR fixes this issue and update macOS build docs.

Closes #20498.

@hebasto
Copy link
Member Author

hebasto commented Nov 29, 2020

Mind considering backporting into 0.21?

@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 29, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

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.

@DrahtBot
Copy link
Contributor

🕵️ @harding @fanquake have been requested to review this pull request as specified in the CODEOWNERS file.

@jonasschnelli
Copy link
Contributor

utACK ef7cd61

@jonasschnelli
Copy link
Contributor

Needs rebase (due to #20478)

@hebasto
Copy link
Member Author

hebasto commented Dec 1, 2020

Rebased ef7cd61 -> 0479464 (pr20527.01 -> pr20527.02) due to the conflict with #20478.

Copy link
Member

@willcl-ark willcl-ark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested 0479464 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

@hebasto
Copy link
Member Author

hebasto commented Dec 3, 2020

@willcl-ark

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 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?

@willcl-ark
Copy link
Member

@willcl-ark

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 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.

@hebasto
Copy link
Member Author

hebasto commented Dec 3, 2020

Updated 0479464 -> 7bf449e (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.

Copy link
Contributor

@jonasschnelli jonasschnelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code review ACK 7bf449e

This change unifies Homebrew packages workflow, and does not change
behavior.
@hebasto
Copy link
Member Author

hebasto commented Dec 4, 2020

Updated 7bf449e -> 03c65e4 (pr20527.03 -> pr20527.04):

@willcl-ark
Copy link
Member

tACK 03c65e4

Building without brew sqlite3 (but with brew installed) now leaves no trace in config.log:

SQLITE_CFLAGS=''
SQLITE_LIBS='-lsqlite3'

vs building with brew sqlite3:

SQLITE_CFLAGS='-I/usr/local/Cellar/sqlite/3.33.0/include'
SQLITE_LIBS='-L/usr/local/Cellar/sqlite/3.33.0/lib -lsqlite3'

@hebasto
Copy link
Member Author

hebasto commented Dec 7, 2020

Updated 03c65e4 -> c932e0d (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 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.

  • (minor) improved robustness of use_bdb check

@willcl-ark
Copy link
Member

With brew sqlite installed, running ./configure --with-sqlite=no I still see a single artefact of sqlite in config.log:

5390: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

@hebasto
Copy link
Member Author

hebasto commented Dec 7, 2020

With brew sqlite installed, running ./configure --with-sqlite=no I still see a single artefact of sqlite in config.log:

5390: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?

@willcl-ark
Copy link
Member

With brew sqlite installed, running ./configure --with-sqlite=no I still see a single artefact of sqlite in config.log:

5390: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?

@hebasto you are right, re-running autogen.sh sorted it!

@laanwj
Copy link
Member

laanwj commented Dec 10, 2020

Code review ACK c932e0d

Copy link
Contributor

@jonasschnelli jonasschnelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code review re-ACK c932e0d

@jonasschnelli jonasschnelli merged commit 86f2007 into bitcoin:master Dec 10, 2020
@hebasto hebasto deleted the 201129-sqlite branch December 10, 2020 12:24
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Dec 10, 2020
This change unifies Homebrew packages workflow, and does not change
behavior.

Github-Pull: bitcoin#20527
Rebased-From: c96d1f6
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Dec 10, 2020
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Dec 10, 2020
@maflcko
Copy link
Member

maflcko commented Dec 10, 2020

Backported in #20612 because this has been marked for backport

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Dec 10, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Q: Compiling with SQLite on macOS
7 participants