Conversation
|
Opened upstream https://codereview.qt-project.org/c/qt/qtbase/+/682915 for Cflags, but can keep workaround until it is reviewed. Also will likely defer removal until 6.11 and add caveat in case anyone was using. I think adding ❯ clang -std=c++17 -c test.cpp -o test.o -I/opt/homebrew/lib/QtCore.framework/Headers -DQT_CORE_LIB
In file included from test.cpp:1:
/opt/homebrew/lib/QtCore.framework/Headers/QtCore:3:10: fatal error: 'QtCore/QtCoreDepends' file not found
3 | #include <QtCore/QtCoreDepends>
| ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
❯ clang -std=c++17 -c test.cpp -o test.o -F/opt/homebrew/lib -I/opt/homebrew/lib/QtCore.framework/Headers -DQT_CORE_LIB
❯ echo $?
0 |
|
We are seeing similar pre-processor errors to what you described earlier when building Octave with Qt6 from Homebrew: Afaict, that is with Qt 6.9.3. Is there a workaround that we could use intermediately? Or should we just wait for Qt 6.10.0? Edit: Link to failed build attempt: https://github.com/gnu-octave/octave/actions/runs/18363007522/job/52310219656#step:10:4739 |
Easiest is waiting for 6.10.0 (or I may apply my upstream patch to 6.9.3 given this PR is waiting behind Python 3.14 PR right now as we only have a single self-hosted Linux runner). Mainly needs the |
Trying this out in EDIT: Looks like for Octave this won't be enough as the QT_CPPFLAGS don't have The above needs a fix in Octave to get
|
|
Thanks for looking into this. If I'm getting this right, Octave should use the Is that a general rule for the preprocessor flags on macOS (and platforms with frameworks)? Or is that only for Qt6? |
If #247555 is merged then yes. Currently, the
At least for macOS frameworks, the preprocessor needs to handle it separate from Some references not specific to this but on frameworks: Will note that many projects don't use Frameworks (or at least in Homebrew we prefer the GNU layout if available). Qt is one of few that only offer Frameworks on macOS and don't officially install symlinks/copies of headers in traditional include directory. |
|
Thank you for clarifying, and for cherry-picking your change to Qt 6.9.3. 🙏 I've talked with other developers of Octave, and we decided to go with taking all Cflags from pkg-config files: It's currently only on the development branch of Octave. And if it causes issues somewhere, we might need to revert or adapt that change. But potentially (and if it turns out that this is all that is needed after #247555 is merged), something like that could be used by Homebrew if you need to rebuild Octave. |
|
Will drop the symlink workaround here since no longer needed by any dependent formula. It also avoids us deviating from other installations (e.g. official, MacPorts, etc). Also, will likely try adding |
|
Actually, may just add Also want to wait for bottling jobs to slow down as GitHub API limits will cause problems for this PR. |
|
QMake does automatically handle this. CMake didn't, but it may be because I'm not running install. Pkg-config will need a For split package, also need to add Linux should already have path in RPATH due to superenv |
|
Will comment out |
Closes #247399
|
Dependent tests were skipped as arm64 linux timed out. Need a way to ignore the result of that runner in workflow until we have a self hosted |
|
Is there any possibility to re-use bottle cache by re-run CI several times? Not sure about this, but just looking for a way to forward. |
|
qt 6.10.1 is out |
|
Superseding with Will be trying a upstream commit for RPATH issue which hopefully will avoid the breakage if we switch to |
Version bump supersedes and closes #247166
Need to re-add header symlink as current pkg-config file needs it. Don't have time right now to add a fix upstream so restoring original logic.This impacts a few formulae which don't use CMake/QMake, e.g. octave, gnuplot, audaciousEDIT: No longer needed after
Note
Dropping below
preserve_rpathchanges for now as not available in brew tag. Can be done in follow up or future release.This PR also applies new
preserve_rpathas users want to usemacdeployqt:@rpath/*install names brew#15354This does introduce some breakage for existing users who may now need to add RPATH to create functional binaries. QMake automatically does this, but other build systems may need some changes in build commands
Comments on PR changes:
qt-*formulae as it has no impact there. Those formulae don't have frameworks.-DQT_EXTRA_RPATHS=#{HOMEBREW_PREFIX}/lib"due to split packages needing help finding other formulae's frameworks. Using a relative path is tricky here so just using absolute to linked prefix. We were already rewriting install names so changing this to rewriting RPATHs isn't similar.