Trying to compile from git sources. After an apparently successful cmake . -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull \\ -DPLUGIN_INSTALL_DIR:PATH=/usr/lib/qt5/plugins The "make" command gives: $ make Scanning dependencies of target kigpart_automoc [ 1%] Automatic moc for target kigpart Generating kig_part.moc [...] [ 94%] Building CXX object CMakeFiles/kigpart.dir/kigpart_automoc.cpp.o In file included from /home/matem/paolini/Git/kdeedu/kig/kigpart_automoc.cpp:2:0: /home/matem/paolini/Git/kdeedu/kig/moc_asyexporteroptions.cpp:9:91: fatal error: ../../../../../misc/euclide/paolini/Git/kdeedu/kig/filters/asyexporteroptions.h: No such file or directory ---------------------------- It turns out that all "moc*.cpp" contain a wrong #include like the following: #include "../../../../../misc/euclide/paolini/Git/kdeedu/kig/kig/kig_view.h" Instead of a simpler "#include "kig/kig_view.h". The above does not work in my setting probably because of the presence of a symbolic link: $ ls -ld ~paolini/Git lrwxrwxrwx 1 paolini matem 30 9 giu 2014 /home/matem/paolini/Git -> /home/misc/euclide/paolini/Git that somehow confuses the automatic creation of the moc* files. If I manually modify this include on each moc file, then compilation goes fine Reproducible: Always Steps to Reproduce: The specific setting of the environment is: ~/Git is a symbolic link to /home/misc/euclide/paolini/Git and /home/misc/euclide is an "automount" point that mounts (locally) the filesystem in /data1/export/ Actual Results: Creation of a strange "../../../../../misc/euclide/paolini/Git/kdeedu/kig/" which "appears" somehow correct (just going up and down on the same path of the filesystem hierarchy) but doesn't work in the present setting: the "misc" directory can be found one more level up.
moc files are generated by the "moc" utility from Qt. Please report this issue directly to Qt developers via https://bugreports.qt.io/
Actually, I am not sure this is a "moc" problem. By using "make VERBOSE=1" I got the exact command executed to obtain one of the moc* files: ------------------------------------------------------------------------------------------------------------- $ /usr/lib/qt5/bin/moc -I/home/matem/paolini/Git/kdeedu/kig/modes -I/home/matem/paolini/Git/kdeedu/kig -I/usr/include/qt5 -I/usr/include/qt5/QtGui -I/usr/include/qt5/QtCore -I/usr/lib/qt5/./mkspecs/linux-g++ -I/usr/include/qt5/QtSvg -I/usr/include/qt5/QtWidgets -I/usr/include/qt5/QtPrintSupport -I/usr/include/KF5/KCrash -I/usr/include/KF5 -I/usr/include/KF5/KParts -I/usr/include/KF5/KIOWidgets -I/usr/include/KF5/KIOCore -I/usr/include/KF5/KCoreAddons -I/usr/include/KF5/KService -I/usr/include/KF5/KConfigCore -I/usr/include/KF5/KJobWidgets -I/usr/include/qt5/QtNetwork -I/usr/include/KF5/KCompletion -I/usr/include/KF5/KWidgetsAddons -I/usr/include/KF5/KXmlGui -I/usr/include/qt5/QtDBus -I/usr/include/qt5/QtXml -I/usr/include/KF5/KConfigWidgets -I/usr/include/KF5/KCodecs -I/usr/include/KF5/KConfigGui -I/usr/include/KF5/KAuth -I/usr/include/KF5/KTextWidgets -I/usr/include/KF5/SonnetUi -I/usr/include/KF5/KI18n -I/usr/include/KF5/KTextEditor -I/usr/include/KF5/KIconThemes -I/usr/include/KF5/KArchive -I/usr/include/qt5/QtXmlPatterns -I/usr/include -DKCOREADDONS_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -DQT_WIDGETS_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -DWITH_GEOGEBRA=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o /home/matem/paolini/Git/kdeedu/kig/moc_popup.cpp /home/misc/euclide/paolini/Git/kdeedu/kig/modes/popup/popup.h ------------------------------------------------------------------------------------------------------------------ As you can see all paths start with "/home/matem/paolini/Git/kdeedu/kig/" *except* the last one: "/home/misc/euclide/paolini/Git/kdeedu/kig/modes/popup/popup.h" that starts with "/home/misc/euclide/...". Actually the two paths lead to the same point. Trying to walk "blindly" from one path to the other by using e sequence of "../" is clearly what "moc" does, but this does not work in my special situation due to the presence of a symbolic link (and perhaps the nfs mount point). I am not sure that I should blame "moc" for the wrong result! ------ during the make process I noticed a sequence of /usr/bin/cmake -E cmake_autogen /home/matem/paolini/Git/kdeedu/kig/CMakeFiles/kigpart_automoc.dir/ debugfull AUTOGEN: Checking /home/misc/euclide/paolini/Git/kdeedu/kig/objects/angle_type.cc where I notice the change of "/home/matem/paolini" into "/home/misc/euclide/paolini" it would be helpful to know how AUTOGEN obtaines the latter path. It is not wrong in itself, indeed /home/matem/paolini/Git is a simbolic link to /home/misc/euclide/paolini/Git !
It seems that different ways to get the current directory are used. Indeed in my situation I get: $ cd Git/kdeedu/kig $ pwd -L /home/matem/paolini/Git/kdeedu/kig $ pwd -P /home/misc/euclide/paolini/Git/kdeedu/kig
I just opened a bug report for qt on this issue: https://bugreports.qt.io/browse/QTBUG-51964
From Qt I was redirected to cmake developer... Actually I *did* try hard to find something about "automoc" in the internet before submitting the bug report, but with very little success. I thought that "moc" was developped by qt, and so I thought of automoc. I don't think I will pursue this "catch the treasure" game further, however. It is way too much time consuming :-( It would be nice however if someone could confirm the issue: $ mkdir -p a/b $ ln -s a/b ab.lnk $ cd ab.lnk $ git pull ... $ cd kig $ cmake ... $ make
The following alias solves the problem for me: alias cmake='PWD=$(pwd -P) cmake'
Is this still an issue?
Yes it is! (answering to comment 7). I tried again the whole procedure (with a fresh checkout of kig) and the issue is *exactly* the same as in my first "Description" here. Moreover I can confirm that the alias alias cmake='PWD=$(pwd -P) cmake' is a workaround, but without that alias the problem is still there.
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
The reported bug seems to have disappeared, possibly due to some change meanwhile. I changed the status to RESOLVED/FIXED Maurizio