-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve cmake build for MSVC #1191
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 7 of 7 files at r1.
Reviewable status: 0 of 1 approvals obtained
As mentioned in the PR, the flow for setting up dependencies is a little different. As a result the CI build for MSVC failed. This is an expected result of the changeset. |
@sphaerophoria can you update the appveyor instructions to set up the dependencies in the new way? |
Since you have changed the way dependencies are being searched, I suggest you enable all of the Travis-CI builds to make sure all of them succeed. We have macOS build, FreeBSD build, Windows cross-compilation build, etc. It's quite possible that changing how dependencies are searched could have broken some of them. Just make a separate commit removing all of |
Thanks for the feedback, will do, wouldn't want to break other builds! |
39b82e4
to
c1ae5a9
Compare
Codecov Report
@@ Coverage Diff @@
## master #1191 +/- ##
========================================
+ Coverage 82.7% 82.8% +<.1%
========================================
Files 82 82
Lines 14646 14646
========================================
+ Hits 12122 12132 +10
+ Misses 2524 2514 -10
Continue to review full report at Codecov.
|
The Windows cross-compilation builds are failing to find libpthread. The library is located at $ find /usr/i686-w64-mingw32 -name '*pthread*'
/usr/i686-w64-mingw32/include/pthread.h
/usr/i686-w64-mingw32/include/pthread_unistd.h
/usr/i686-w64-mingw32/include/pthread_signal.h
/usr/i686-w64-mingw32/include/pthread_time.h
/usr/i686-w64-mingw32/include/pthread_compat.h
/usr/i686-w64-mingw32/lib/libpthread.dll.a
/usr/i686-w64-mingw32/lib/libpthread.a
/usr/i686-w64-mingw32/lib/libwinpthread.dll.a
/usr/i686-w64-mingw32/lib/libwinpthread.a
/usr/i686-w64-mingw32/lib/libwinpthread-1.dll
$ find /usr/x86_64-w64-mingw32 -name '*pthread*'
/usr/x86_64-w64-mingw32/include/pthread.h
/usr/x86_64-w64-mingw32/include/pthread_unistd.h
/usr/x86_64-w64-mingw32/include/pthread_signal.h
/usr/x86_64-w64-mingw32/include/pthread_time.h
/usr/x86_64-w64-mingw32/include/pthread_compat.h
/usr/x86_64-w64-mingw32/lib/libpthread.dll.a
/usr/x86_64-w64-mingw32/lib/libpthread.a
/usr/x86_64-w64-mingw32/lib/libwinpthread.dll.a
/usr/x86_64-w64-mingw32/lib/libwinpthread.a
/usr/x86_64-w64-mingw32/lib/libwinpthread-1.dll The build scripts tell pkg-config and CMake's own find utilities to look into
|
c1ae5a9
to
b843cd5
Compare
The build scripts for this are in |
@nurupo I've replaced the Threads::Threads module with one that I thought was equivalent and also handles win32 pthreads correctly. It's quite possible that I accidentally overrode the mingw version as they're both win32 but are handled differently. I'll do my best to avoid touching the build scripts and adapting my changes to avoid changing behavior for non MSVC targets as much as possible. |
96c8e01
to
172f679
Compare
Alright CIs passed https://travis-ci.org/TokTok/c-toxcore/builds/431320188?utm_source=github_status&utm_medium=notification I've squashed down the last commit and stripped the travis. Had to tell Findsodium.cmake that I wanted the static variant and only enable pthreads-win32 on msvc. |
Would it still work if you have only shared sodium library? libtoxcore is packaged in Debian Sid and the libsodium is a shared library there. |
That's a good point, do you happen to know what pkg_use_module did under the hood to prioritize shared vs static linking before? I can change my PR to try one and fallback on the next |
172f679
to
71dc932
Compare
I've updated the PR to try to link sodium statically before linking it shared. |
602e602
to
f4e2065
Compare
Closing/Reopening PR to re-trigger travis since it doesn't look like my change introduced the failure. |
I don't think that works. You can push an amended commit, that triggers it. |
I've restarted the build. |
Thanks, I think the PR is ready to go now. |
It used Cmake's PkgConfig module c-toxcore/cmake/ModulePackage.cmake Lines 15 to 17 in c8359c8
Here is documentation for it: https://cmake.org/cmake/help/v3.0/module/FindPkgConfig.html It describes a common case and a case when you explicitly ask for a static library. We used the common case. I think the common case searches for shared first and then falls back to static. Would need to test pkg-config on my system to know for sure. I could test that if you could wait for ~8 hours. |
Btw, your |
cmake/Dependencies.cmake
Outdated
find_library(NSL_LIBRARIES nsl ) | ||
find_library(RT_LIBRARIES rt ) | ||
find_library(SOCKET_LIBRARIES socket ) | ||
|
||
# For toxcore. | ||
pkg_use_module(LIBSODIUM libsodium ) | ||
# for toxcore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For toxcore.
to match the For toxav.
below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
cmake/Dependencies.cmake
Outdated
PKGCFG_NAME opus | ||
LIB_NAMES opus | ||
PATH_SUFFIXES opus | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Format closing parentheses consistently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
cmake/Dependencies.cmake
Outdated
PATH_SUFFIXES opus | ||
) | ||
|
||
simple_find_package(Vpx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Order the arguments consistently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
0b8755a
to
3250903
Compare
3250903
to
886b5f4
Compare
Heh, pkg-config just tells to link against $ pkg-config --libs libsodium
-L/root/prefix/i686/lib -lsodium $ pkg-config --static --libs libsodium
-L/root/prefix/i686/lib -lsodium |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 5 of 7 files at r1, 2 of 3 files at r2, 1 of 2 files at r4.
Reviewable status: 0 of 1 approvals obtained (waiting on @sphaerophoria and @iphydf)
cmake/Dependencies.cmake, line 27 at r4 (raw file):
# Try to find both static and shared variants of sodium set(sodium_USE_STATIC_LIBS ON)
Make it look for shared first and then fallback to static, because that's what the previous behavior was.
I'm honestly not sure. I'm way more familiar with the linux side of things than windows. I just started hacking away until things built. I read that cmake chooses the .so first with find package and falls back on static i general. Not sure what MSVC does. I've updated the PR with shared followed by static instead of the other way around to keep compatibility with old builds. I've also changed from if (NOT sodium_FOUND) to if (NOT TARGET sodium), i had trouble in an ubuntu 14.04 build I was trying with qtox which seems to be resolved with that solution |
886b5f4
to
242217f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r5.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @sphaerophoria and @iphydf)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 5 of 7 files at r1, 2 of 3 files at r2, 1 of 1 files at r5.
Reviewable status:complete! 1 of 1 approvals obtained (waiting on @sphaerophoria and @iphydf)
242217f
to
f87f871
Compare
Welp, looks like we still managed to break the Windows cross-compilation builds: https://travis-ci.org/TokTok/c-toxcore/builds/432322743
|
Current cmake files don't handle MSVC builds very well. They don't support toxav and only support libs being in a specific location. I've adjusted them to build on MSVC for me a lot better.
After this I was able to build/link qtox and have an audio/video call with a friend on linux using the toxlib I built.
This change is