D14958: Fix kdev_perforce unittest to run on kde windows CI and everywhere else.

Morten Volden noreply at phabricator.kde.org
Thu Aug 23 14:15:27 BST 2018

volden added inline comments.


> kfunk wrote in test_perforce.cpp:58
> Scanning recursively through the build dir seems pretty unclean to me.
> Wouldn't a simple `QStandardPaths::findExecutable("p4clientstub", P4_BINARY_DIR);` with `P4_BINARY_DIR` initialized with `CMAKE_RUNTIME_OUTPUT_DIRECTORY` work?
> See: https://cmake.org/cmake/help/v3.9/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY.html

As far as I can tell from cmake documetation


CMAKE_RUNTIME_OUTPUT_DIRECTORY is under the section "Variables that Control the Build". I take that to mean it is meant to be set and not read. That would also correspond with the fact that it gives me an empty path when I initialize P4_BINARY_DIR with it.

Under "Variables that Provide Information" section there is:

CMAKE_CURRENT_BINARY_DIR gives me /home/mvo/kde/build/extragear/kdevelop/kdevelop/plugins/perforce/tests (The executable is under /home/mvo/kde/build/extragear/kdevelop/kdevelop/plugins/perforce/p4clientstub and at a different relative location under windows)
<PROJECT-NAME>_BINARY_DIR gives me /home/mvo/kde/build/extragear/kdevelop/kdevelop/
PROJECT_BINARY_DIR gives me /home/mvo/kde/build/extragear/kdevelop/kdevelop/ (because there is only one project declaration in all of kdevelop)

I'm not a big fan of scanning the entire build dir either. but at least it is only done once pr. testrun

  R32 KDevelop


To: volden, #kdevelop, kfunk
Cc: kfunk, kdevelop-devel, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180823/280a4816/attachment.html>

More information about the KDevelop-devel mailing list