Relative paths getting turned into absolute in project file -- new "feature" in Qt 5.5?
-
Hello, I am new to the forum here. Sorry for the long details here, but they are relevant. I'm passing the following command to create a project file:
INSTALL_DIR=/usr/gapps/asciviz/blockbuster/dev/chaos_5_x86_64_ib /usr/local/tools/qt-5.5.1/bin/qmake -project -d -d -d -nopwd -Wall 'LIBS += /usr/gapps/asciviz/blockbuster/dev/chaos_5_x86_64_ib/lib/libboost_thread.a -lXtst -lXinerama -lsmovie -lsrwpng -ljpeg -llzo2 -lz -llzma -lm ' "INCLUDEPATH += libdmx ../common ../RC_cpp_lib ../config /usr/gapps/asciviz/blockbuster/dev/chaos_5_x86_64_ib/include $(echo -I/usr/X11R6/include -I/usr/X11/include -I/usr/X11R6/include -I/usr/X11/include | sed -e s/-I//g ) " "MAKEFILE = Makefile.qt.include" "DEFINES += NO_BOOST USE_MPI=1 USE_STDARG HAVE_STDLIB_H=1 HAVE_STRING_H=1 HAVE_UNISTD_H=1 HAVE_STDARG_H=1 USE_STDARG=1 MALLOC_RET_VOID=1 USE_DMX USE_QT " "QT += network" "QT += opengl" "HEADERS = errmsg.h events.h ImageCache.h ../RC_cpp_lib/stringutil.h ../RC_cpp_lib/timer.h ../config/version.h MovieCues.h errmsg.h pure_C.h util.h blockbuster_qt.h sgi-rgbFrame.h convert.h smFrame.h ../RC_cpp_lib/pathutil.h pngFrame.h splash.h pnmFrame.h tiffFrame.h ../RC_cpp_lib/Prefs.h Renderer.h glRenderer.h dmxRenderer.h " "FORMS += MovieCueWidget.ui BlockbusterControl.ui InfoWindow.ui" "" "RESOURCES += images.qrc" ./main.cpp blockbuster_qt.cpp movie.cpp timer.C pure_C.c frames.cpp slave.cpp cache.cpp common.cpp Prefs.C sgi-rgbFrame.cpp convert.cpp smFrame.cpp pngFrame.cpp splash.cpp pnmFrame.cpp tiffFrame.cpp libdmx/dmx.c MovieCues.cpp events.cpp ImageCache.cpp Renderer.cpp util.cpp settings.cpp errmsg.cpp Renderer.cpp x11Renderer.cpp glRenderer.cpp dmxRenderer.cpp
When the command completes, in Qt 5.1.x and earlier, I get the following line in my blockbuster.pro file:, which is correct.
SOURCES += blockbuster_qt.cpp \ cache.cpp \ common.cpp \ convert.cpp \ dmxRenderer.cpp \ errmsg.cpp \ events.cpp \ frames.cpp \ glRenderer.cpp \ gprof-helper.c \ ImageCache.cpp \ iotest.C \ main.cpp \ movie.cpp \ MovieCues.cpp \ newcache.cpp \ pngFrame.cpp \ pnmFrame.cpp \ Prefs.C \ pure_C.c \ qrc_images.cpp \ Renderer.cpp \ settings.cpp \ sgi-rgbFrame.cpp \ SidecarServer.cpp \ slave.cpp \ smFrame.cpp \ splash.cpp \ tiffFrame.cpp \ timer.C \ util.cpp \ x11Renderer.cpp
But in Qt 5.5, I get this:
SOURCES += /main.cpp \ /blockbuster_qt.cpp \ /movie.cpp \ /timer.C \ /pure_C.c \ /frames.cpp \ /slave.cpp \ /cache.cpp \ /common.cpp \ /Prefs.C \ /sgi-rgbFrame.cpp \ /convert.cpp \ /smFrame.cpp \ /pngFrame.cpp \ /splash.cpp \ /pnmFrame.cpp \ /tiffFrame.cpp \ /libdmx/dmx.c \ /MovieCues.cpp \ /events.cpp \ /ImageCache.cpp \ /Renderer.cpp \ /util.cpp \ /settings.cpp \ /errmsg.cpp \ /x11Renderer.cpp \ /glRenderer.cpp \ /dmxRenderer.cpp \ common.cpp \ blockbuster_qt.cpp \ events.cpp \ errmsg.cpp \ settings.cpp \ movie.cpp \ frames.cpp \ slave.cpp \ util.cpp \ SidecarServer.cpp \ smFrame.cpp \ splash.cpp \ glRenderer.cpp \ x11Renderer.cpp \ dmxRenderer.cpp \ pnmFrame.cpp \ pngFrame.cpp \ tiffFrame.cpp \ sgi-rgbFrame.cpp \ cache.cpp \ convert.cpp \ ImageCache.cpp \ Renderer.cpp
The generation of sources with a slash prepended, e.g., "/blockbuster_qt.cpp" etc. causes errors like this when I run make.
make[3]: *** No rule to make target `/blockbuster_qt.cpp', needed by `blockbuster_qt.o'. Stop.
Is this intentional new behavior? It prevents me from upgrading to Qt 5.5 because I just cannot seem to stop this behavior.
Thanks.
-
Hi and welcome to devnet,
Looks strange, could you test that again with Qt 5.6 beta ?
-
@SGaist Thanks, I'll check that out. I can confirm that version 5.4.2 works with this command. It's just 5.5.1 that is breaking so far for me.
@poorchef Unfortunately, I cannot build Qt 5.6 on our clusters. I get the following error:
gmake[3]: Entering directory '/tmp/dpkg-mkdeb.UiY9aTUtgB/src/qt-everywhere-opensource-src-5.6.0-alpha/qt3d/tools/qgltf' g++ -c -pipe -Wno-ignored-qualifiers -O2 -std=c++0x -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DASSIMP_BUILD_NO_OWN_ZLIB -DASSIMP_BUILD_NO_COMPRESSED_IFC -DASSIMP_BUILD_NO_Q3BSP_IMPORTER -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I../../src/3rdparty/assimp -I../../src/3rdparty/assimp/code -I../../src/3rdparty/assimp/code/BoostWorkaround -I../../src/3rdparty/assimp/include -I../../src/3rdparty/assimp/include/assimp/Compiler -I../../src/3rdparty/assimp/contrib/ConvertUTF -I../../src/3rdparty/assimp/contrib/irrXML -I../../src/3rdparty/assimp/contrib/poly2tri/poly2tri -I../../src/3rdparty/assimp/contrib/clipper -I../../src/3rdparty/assimp/contrib/unzip -I/tmp/dpkg-mkdeb.UiY9aTUtgB/src/qt-everywhere-opensource-src-5.6.0-alpha/qtbase/include -I/tmp/dpkg-mkdeb.UiY9aTUtgB/src/qt-everywhere-opensource-src-5.6.0-alpha/qtbase/include/QtCore -I.moc -I/tmp/dpkg-mkdeb.UiY9aTUtgB/src/qt-everywhere-opensource-src-5.6.0-alpha/qtbase/mkspecs/linux-g++ -o .obj/qgltf.o qgltf.cpp qgltf.cpp: In member function 'void GltfExporter::exportTechniques(QJsonObject&, const QString&)': qgltf.cpp:1939: error: template argument for 'template<class Key, class T> class QHash' uses local type 'GltfExporter::exportTechniques(QJsonObject&, const QString&)::ProgramNames' qgltf.cpp:1939: error: trying to instantiate 'template<class Key, class T> class QHash' qgltf.cpp:1939: error: invalid type in declaration before ';' token qgltf.cpp:1949: error: 'struct GltfExporter::ProgramInfo' has no member named 'name' qgltf.cpp:1950: error: 'struct GltfExporter::ProgramInfo' has no member named 'name' qgltf.cpp:1958: error: 'struct GltfExporter::ProgramInfo' has no member named 'coreName' qgltf.cpp:1959: error: 'struct GltfExporter::ProgramInfo' has no member named 'coreName' qgltf.cpp:1998: error: 'struct GltfExporter::ProgramInfo' has no member named 'name' qgltf.cpp:2029: error: 'struct GltfExporter::ProgramInfo' has no member named 'coreName'
-
No need to built it yourself, there are now the pre-built package for the beta.
In any case, I've could reproduce this locally. You can check the bug report system to see if it's something known. If not please consider opening a new report providing as much details as you can to reproduce this. Providing a minimal example that helps reproduce this would be a big plus.