qt 5.4 build failure to replace existing qt5.3 in the same place
René J.V. Bertin
rjvbertin at gmail.com
Mon Jan 12 10:58:13 PST 2015
On Monday January 12 2015 11:48:01 Ryan Schmidt wrote:
> > Can that be considered a bug? Can I safely do a search and remove of -I/opt/local/include/qt5 in the generated makefiles (or wherever that option is stored) before starting the build?
>
> Yes, incorrect -I flags would be a bug that you should report to the developers. I don't know this build system so I don't know if the change you propose is the correct fix.
The change I proposed does work, but seems to be unreliable when I implement it as a reinplace in the Portfile's post-configure phase. At least once just now the 2 "incriminated" .ninja files (because that's what we're talking about) were recreated after I had redone a full configure
i.e., summarised to standard Unix commands:
#1> (cd build/qtbase/qmake ; make distclean)
#2> (cd build ; ../qt-everywhere*/configure <configure flags>)
#3> sed -e "s|-I/opt/local/include/qt5||g" build/qtwebengine/src/core/*/obj/src/core/QtWebEngineCore.ninja
#4> (cd build ; make)
after that make command failed I found that the 2 edited .ninja files had timestamps that were younger than the start of the make command. I guess that the build system detects changes, though I don't see why it didn't when I restarted at #2 ...
I also don't see an explicit reference to the target headers dir (/opt/local/include/qt5) in the qtwebengine .pro files, so a proper fix at that level may not even be possible ...
R.
More information about the macports-dev
mailing list