#41 0.7.1 fails to build: QFSFileEngine::open: No file name specified

[Yuri]

[10/135] cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/lupdate @ -ts /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_zh.ts
FAILED: /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_zh.ts 
cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/lupdate @ -ts /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_zh.ts
QFSFileEngine::open: No file name specified
lupdate error: List file '' is not readable.
[11/135] cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/lupdate @ -ts /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_de.ts
FAILED: /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_de.ts 
cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/lupdate @ -ts /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_de.ts
QFSFileEngine::open: No file name specified
lupdate error: List file '' is not readable.
[12/135] cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/lupdate @ -ts /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_el.ts
FAILED: /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_el.ts 
cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/lupdate @ -ts /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/libmolsketch_el.ts
QFSFileEngine::open: No file name specified
lupdate error: List file '' is not readable.
[13/135] cd /usr/ports/science/molsketch/work/.build/libmolsketch && /usr/local/lib/qt5/bin/rcc --name toolicons --output /usr/ports/science/molsketch/work/.build/libmolsketch/qrc_toolicons.cpp /usr/ports/science/molsketch/work/Molsketch-0.7.1/libmolsketch/tools/toolicons.qrc
ninja: build stopped: subcommand failed.

Qt-5.15.2
OS: FreeBSD 12.2

[Hendrik Vennekate]

Hi Yuri! That is a bit confusing as those files are indeed part of the package (*.tar.gz).
Which build system are you using? Also: Why is there an @ after /usr/local/lib/qt5/bin/lupdate?

[Yuri]

Why is there an @ after /usr/local/lib/qt5/bin/lupdate?

I don't know. The build only breaks when built with ninja backend, and succeeds with gmake backend.

[Yuri]

This is likely a cmake bug: https://gitlab.kitware.com/cmake/cmake/-/issues/21931

[Craig Scott]

The command comes from qt5_create_translation(), which is provided by Qt, not CMake. Looking at that command's implementation, you can get a bare @ with nothing following it if it finds ts files but no sources. Please look into the implementation of that command and how your project is calling it. If you believe you are not misusing it, then the Qt issue tracker would be the appropriate place to report a problem.

[Hendrik Vennekate]

Ah, ok, thanks a lot for spotting this, Craig. I'll check it out. Interestingly enough, this seems to have worked both on my machine (OpenSUSE), as well as, e.g. Fedora. Probably depends on the version of qt_create_translation() used then?
In the mean time two hints:
* you can always alternatively use qmake (in fact I use it myself during development, so there is somewhat of a chance that I might have missed some things in the cmake build, as I only check that occasionally)
* unfortunately, when removing the Qt4 support, I forgot that the settings contain the path to the libobabeliface.so. This used to be named libobabeliface-qt5.so, so it would probably be a good idea to add a link with that name during the build process (libobabeliface-qt5.so -> libobabeliface.so)

[Hendrik Vennekate]

Hi Yuri! Quick question: which version of Qt are you using? There seems to have been a change to Qt5LinguistToolsMacros.cmake
for instance https://github.com/qt/qttools/commit/a9790627873d17f91f29c9bd8be0fb609ec29f03, but reverting that particular change does not appear to lead to the error you observed, so I'm still not quite able to reproduce it...

[Yuri]

qt5-\5.15.2

[Hendrik Vennekate]

Hi Yuri! Ok, thanks -- probably missed that in your original post. The key difference is the use of Ninja, though, as you wrote in the cmake bug report. Indeed with the make backend, the same target is generated, but it is not executed as the file (here: the *.ts file) already exists.
And so, yes, Craig is also correct in pointing out that I did use the wrong function here: it should have been qt_add_translation instead of qt_create_translation (or qt5_... for the version-dependent pendant). But one might argue that the cmake bug report still has some merit in that Ninja really behaves differently than gmake. Not entirely sure, though, if Ninja is supposed/able to replicate the behavior of other build systems.

At any rate the fix is this commit. If you want to build using Ninja, you might want to apply this using some patch system -- or you can just wait for the next version to come out (which should be fairly soon, as I also still have to somewhat fix the fall-out of the Qt4 support removal).

Thanks again for reporting!
Cheers,
Hendrik

[Yuri]

Hi Hendrik!

Thank you for fixing it!

I will try when the next release will come out, because I've switched the port to gmake as a workaround for now,

Best,
Yuri