Adjust build_lib.sh for Windows #28
Comments
@leviat thanks for the issue! I'm really eager to solve well this one. First, it is possible to do different things depending on target in So, what are the requirements for compiling
|
(Note: I have a Windows machine, so I'm not talking about cross-compiling, but about a direct compiling on Windows (: ) |
Well, I kind of sent an unfinished reply and then deleted it without copying the content... so here again 😄 Thanks for taking on this issue! I work both on Linux and on Windows but fixing os-specific dependencies might not really be my forte. My current compilation of Requirements (probably not complete):
It probably suffices to have the Qt and VS versions match but that's what currently works for me. CompilingTo compile DOtherSide from the Windows command line cmake -G "Visual Studio 12 2013 Win64" ..
"c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64
msbuild.exe Project.sln This will generate the project files for VS, set some environment variables for VS compilation and then build the project. We probably should forward target parameters like LinkingQtSo currently I compile DOtherSide with Unix Makefiles and cygwin. To correctly link the Qt libraries, I also made some adjustments in // On Linux and Windows, libraries are named "Qt5Core", not "QtCore" as on OSX
let linux_qt_lib_ver = if target.contains("linux") || target.contains("windows") { "5" }
else { "" };
// On windows include qt folder
if cfg!(target_os = "windows") {
println!("cargo:rustc-link-search=native=C:/Qt/5.6/msvc2013_64/lib");
} The second half is quite ugly. If there was a way to retrieve the library path from the cmake process before, that would be a lot nicer and less error prone. The building process will just fail at this point when another Qt version is used or if it has been installed somewhere else. C++ std librariesThis is the part where it fails at my end right now. We include stdc++ libraries without some proper black magic to retrieve the right files and put them into the right places. The "right" way would be to use the Visual Studio C++ libraries I guess. The linking process somewhere already links to So well, that's my current status. If you have any nifty ideas how to improve the ugly workarounds, that would be great! |
Just wanted to give a quick update: |
I really don't like the way paths are hardcoded, but I guess, that's what we have |
I can rewrite the hardcoded paths for Visual Studio in the build-script because there are some env-vars for that. There are two problems left, though: Currently, the only way to find the correct Qt folders is to rely on the user to provide them. I don't know how to handle this neatly, though. Even Cmake needs to know the path to the Qt root folder in order to find its modules. (This is done by setting the CMAKE_PREFIX_PATH or include it into PATH.) A more elegant solution would be to have the user pass the Qt path to the build-script as an argument. However, I have no clue how to do that. So I guess we opt for the "user sets the CMAKE_PREFIX_PATH"?😕 Second, I haven't got it to work with VS 14 yet. So there's still the hardcoded linking part in the cargo config. Gonna see into it the next days unless you know a reason why it wouldn't work with. :) |
I think it's okay to depend on |
@leviat I'm not sure you haven't discovered this, but there are env variables set by Visual Studio such as |
Thanks, that's what I meant when I said I could rewrite the hardcoded paths for VS in the build scripts. However, the problem was with the cargo config. We can't use env vars there but have to specify the linker in it unless we get the project to work on all VS versions. It doesn't run on VS 14 right now and to be honest, I don't have a clue why 😕 |
@leviat well, I just built it on VS 14. I had problems with 64-bit Qt (5.8) though, being able to build only with 32-bit Qt (5.7) version. |
New suggestion. Instead of trying to automagically call the right VS version, we do the following:
set CMAKE_PREFIX_PATH=C:\Qt\5.4\msvc2013_64_opengl
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64 Specifying
That should get rid of all the current hard-coded stuff and let the user handle all the versioning stuff by hand. |
Hello everybody, I hacked together a simple I'm not an expert on Windows but AFAIK CMake finds the environment variables itself w/o any user interaction. At least on my test machine it worked outside of the Visual Studio Bash. I did not have any linker problems mentioned by @leviat. |
@flanfly CMake certainly is able to access the env-vars itself. However, on Windows, Qt does not set any by default. The easiest way to fix that is to either temporarily set the env-var The script will work for you since you have VS 14 and the corresponding Qt version. However, it is not uncommon to have more than one Visual Studio on Windows and to use an older one, e.g. VS 12, due to other library dependencies. In that case, your script can not been used since it will default to VS 14. Generally, I think we should use your code as a basis to improve on. Adding |
I see. The build script checks the CMake indeed uses the latest MSVC it finds. I added some code so you can change this behavior by setting the generator you want in |
Hmm.. I tried to set
Anyone got a clue what happened here? |
@leviat, what cmake version do you use? |
@flanfly I'm working with CMake 3.7.1 😕 |
I propose to adjust the current build script as it is not usable on Windows systems due to two reasons:
Windows does not natively run .sh scripts unless one has installed the shell via cygwin or activated the linux-shell on Windows 10's developer mode. Still, we could add a batch script to make life easier.
cmake
defaults to the MSVCC generator on Windows and callingmake
consequently results in an error since no make files have been generated. We could either explicitly callcmake -G "Unix Makefiles" ..
or run MSVCC's compiler. I haven't tried the latter yet but generating Unix Makefiles works fine on my system with Windows 10. Again, avoiding cygwin and the like would make life a lot easier, though. ;)The text was updated successfully, but these errors were encountered: