Do not install ocsync to subfolder

[dschmidt]

Hey,

I would like to be able to run the client from the Craft Root without further modifications or moving files around, for that ocsync.dll needs to be installed to bin/. I could just change the RUNTIME DESTINATION but I feel the RPATH has caused us more trouble in the past than it did us good:
Just look at the commit history: https://github.com/owncloud/client/search?q=rpath&type=Commits

So I'm voting to get rid of it now and rename the ocsync target, to not clash with branded builds.
I've verified that this way it's possible to run owncloud.exe from Craft Root, owncloud executable from build dir and from CMAKE_INSTALL_PREFIX on Linux - I just couldn't test macOS.

I don't care for the actual name, just that it's not installed to a subfolder.
Instead of ocsync_${APPLICATION_EXECUTABLE} we could maybe use ${APPLICATION_SHORTNAME}ocsync (or ${APPLICATION_SHORTNAME}sync_private) analogue to ${APPLICATION_SHORTNAME}sync. Other suggestions also welcome.

I can also set a variable on top level CMakeLists.txt to have the naming logic only in one place, but then I need a new name for this again.

[dschmidt]

Btw does libsync completely abstract ocsync? Then we possibly don't need to link everything against ocsync but only against libsync (?).

[ogoffart]

Good, I've had the same problem when doing the AppImage.

client/admin/linux/appimage/script.sh

Line 23 in d777fde

cp /build/appdir/usr/lib/owncloud/* /build/appdir/usr/lib

Btw does libsync completely abstract ocsync?

I don't think it does. Because of the common static library.

[ogoffart]

So there is ${APPLICATION_EXECUTABLE}sync and, with this patch, ocsync_${APPLICATION_EXECUTABLE}

I'd vote for renaming it ${APPLICATION_EXECUTABLE}csync
or ${APPLICATION_EXECUTABLE}_csync. Rationale: then the library starts with libowncloud... and are easier to find in the lib directory. (Not a very strongly held opinion)

[ogoffart]

Overall, 👍
Even if we can bikeshed on the name

[ogoffart]

Note, there is a synclib_NAME cmake variable. Maybe we could add a csync_NAME variable as well for consitency

[dschmidt]

Good points, I just wanted to use something to get started. Happy to rename it to whatever, as I said - I don't care at all about the actual name.

Sounds good - will do it with that CMake variable and probably just use ${APPLICATION_SHORTNAME}csync (analogue to ${APPLICATION_SHORTNAME}sync).

[guruz]

Compiles for my on macOS (had to clean a bit in my build dir though).

.app also still is properly running

../install/owncloud.app//Contents/MacOS
../install/owncloud.app//Contents/MacOS/owncloud_crash_reporter
../install/owncloud.app//Contents/MacOS/libocsync_owncloud.2.5.0.dylib
../install/owncloud.app//Contents/MacOS/owncloudcmd
../install/owncloud.app//Contents/MacOS/owncloud
../install/owncloud.app//Contents/MacOS/libowncloudsync.dylib
../install/owncloud.app//Contents/MacOS/libowncloudsync.2.5.0.dylib
../install/owncloud.app//Contents/MacOS/libocsync_owncloud.0.dylib
../install/owncloud.app//Contents/MacOS/libqt5keychain.0.dylib
../install/owncloud.app//Contents/MacOS/libocsync_owncloud.dylib
../install/owncloud.app//Contents/MacOS/libowncloudsync.0.dylib
...

[guruz]

(Might need packaging changes for DEB and RPM)

[dschmidt]

(it will, yes)

[jnweiger]

fine with me.
Packaging changes are identified as https://gitea.int.owncloud.com/ownbrander/scripting/commit/0bd459d6d357e021be765e2caae4749d131f568f

test builds cannt work before the final new names are coded there.