@johnco3 said in porting qmake pro file to mac - library issue:
how I should use or handle the environment variables that point to the homebrew directories?
I have a sample project (my own "living cheatsheet") that compiles a Qt GUI for mac (and other platforms). You don't have to take my word for it, you can look at the Github "Actions" (continuous integration) to see that the builds are succeeding.
My "cheatsheet" project:
uses homebrew: https://github.com/219-design/qt-qml-project-template-with-ci/blob/master/tools/ci/provision_mac.sh#L10
makes minor use of macx blocks in pro/pri files
For my baseline project, the only macx blocks I seem to need are the following "quality of life improvements":
ios|macx {
# the lines below suppress warnings generated by Qt's header files: we tell
# Clang to treat Qt's (mac) Framework headers as "system headers":
QMAKE_CXXFLAGS += -iframework $$[QT_INSTALL_LIBS]
QMAKE_CXXFLAGS += -isystem $$[QT_INSTALL_LIBS]/QtCore.framework/Headers
}
and
ios|macx {
# Disable a couple that are more onerous to comply with on Mac
QMAKE_CXXFLAGS += "\
-Wno-error=missing-noreturn \
-Wno-error=sign-conversion \
"
}
(in the file https://github.com/219-design/qt-qml-project-template-with-ci/blob/master/compiler_flags.pri)
However, the baseline project does not link to anything from homebrew.
On another project (not public on github), here are some other snippets I have used:
macx {
# MacOSX homebrew puts the mysql.h header elsewhere:
QMAKE_CXXFLAGS += -isystem /usr/local/include/mysql
}
macx {
LIBS += -L/usr/local/lib -lmysqlclient
}
Once your code compiles, you will very likely find yourself face-to-face with another common MacOS hurdle: the app bundle. Reference: https://developer.apple.com/go/?id=bundle-structure
In order to make a bundle that will launch (so you can actually launch your app), the Qt "magic" you will need is macdeployqt:
https://github.com/219-design/qt-qml-project-template-with-ci/blob/master/build_app.sh#L91
