Qt Creator + VC19 (MSVC2015) + WinSDK8.1
No Qt itself used. Just console application std+boost+catch+easyloggingpp
VC\bin and WinSDK\bin both are in a system path variable.
all includes and lib paths configured in a pro file.
I need to move them out from project file to build this project on various machines (all windows but different locations of the used libraries).
I think that cl.exe can read this from LIB and INCLUDE env variables, but if I do this (set headers and libraries paths from bat file or in a project settings in QT Creator) it doesn't work, QtC reports me that can't find some headers.
Could you clarify for me:
Should Qt Creator read LIB and INCLUDE variables for the build and parsing? What is right steps to make it working?
If Qt Creator can't read the env variables , then what is right way to remove the dependency of absolute paths in project build with qmake?
You obviously have Visual Studio compiler and other standard library paths hardcoded as absolute in your project file?
All the Visual Studio or other compiler settings e.g. tool chain location are normally read by Qt Creator from compiler kit. Adding Compilers article clarifies on that. That is the first thing to configure as long as your system has Visual Studio installed. Having configured compiler kit you will be able to add one to your current project build: Configuring Projects article.
And in case if you build from command line with qmake and jom: your build script may execute the Visual Studio standard environment batch script file like:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\VcVarsAll.bat" amd64
Mind the target bitness (32/64) and actual location of your Visual Studio. There is MSDN article for that: Setting the Path and Environment Variables for Command-Line Builds.
Related
I am working with Cyclone DDS, and they have two builds,
c build (contains multiple files in the bin folder)
and c++ build (contains DLL file in the bin)
after Cyclones DDS installation, I have to set these bin paths in system environment variables.
how can I avoid this? I need to set them in the visual studio 2017 itself. without setting paths in the system environment
or can I copy bin files into my project directory? so that I can use the project file on any PC which has visual studio 2017 without reinstalling CycloneDDS?
Windows by default will prefer .DLL files in the same directory as the .EXE. So while developing, you can put them in your Visual Studio Debug and Release folders. For other people, you include the DLL's in the installer.
The exception is the *140.dll stuff, for which you need the Visual C++ redistributable. That's installed as part of Visual Studio 2017, but can also be distributed independently (hence the name).
I added the opencv library and include file to visual studio 2019. (Property pages / VC++ directories / include directories & library directories. also, linker / input / and add the name of the library to this part).Also, I added the bin file to the environment variables. It's working well but every time that I want to work with OpenCV I must do all these things again. This is really boring
Is there another solution to add these files? (I mean no need to add files again)
If you are really looking for the fastest option I would recommend using vcpkg.
Once you set it up and install your needed library, using it in your project is as simple as using the standard library, you just have to include the library headers.
CMake can generate project files for several prominent IDEs, such as Microsoft Visual Studio, Xcode, and Eclipse CDT. It can also produce build scripts for MSBuild or NMake on Windows; Unix Make on Unix-like platforms such as Linux, macOS, and Cygwin; and Ninja on both Windows and Unix-like platforms.
I use cmake and Visual Studio and have the following directory structure:
workspace
CMakeLists.txt
project1
src
project2
src
build
The idea behind this is an out-of-source build, so that the generated build files by cmake do not spoil my src folders. This is also described here as top answer: Looking for a 'cmake clean' command to clear up cmake output
However, if I generate the visual studio project being in the build directory using the CMakeLists.txt in the workspace directory like so:
cmake ..
, then everything will be created fine but when I open my visual studio solution and add a file to any of the projects, it will be added into the build folder of the corresponding project...
Of course, this is incorrect. It should put the file in the corresponding directory of the src path. Also, it should show the directory structure. So, if I have:
workspace
project1
src
package1
module1.cpp
module2.cpp
package2
module3.cpp
module4.cpp
, then naturally my visual studio project should show both the package folders. I realize that visual studio's filters do not offer this functionality. But when I hit "Show all files", it usually switches to a view where I can see usual file system directories, which is exactly what I want - only that it should have its root in the corresponding src folder and not in the build path.
Can I arrange this somehow?
Your quandry is that you want to generate a build-file set, with CMake, that is displaced from
the source tree and then in the generated build-file set run an IDE project
that is not displaced from the source tree. You can't have it both ways.
The CMake build directory, whether in-source or out-of-source, is the
directory in which CMake will generate build files for your project,
for some target build system. These artifacts are of service to the end-user who
wants to build your project from packaged source. You need to distinguish the target
build system from your development environment. Your development environment
is a personal productivity choice that has no essential link with the target build system.
It is just co-incidence that your target build system is Visual Studio and so
is your development environment. Imagine instead that your development environment is, say, Code::Blocks,
and your target build system is GNU Make, with CMake employed to generate the GNU Make build files.
In that case you have a Code::Blocks .cbp project file that defines
your development project, and a CMakeLists.txt file that defines a distributable
GNU Make build.
The CMake project and the Code::Blocks project have no connection with each other
except the connections you choose to make in terms of common tools, files and targets.
You might have more files and/or targets in your development project than you
ever choose to reflect in the CMakeLists.txt. The target toolchain could be different
from the development toolchain. As far as the CMake project is concerned it doesn't matter
at all where the Code::Blocks .cbp file resides or if such a thing exists, although you will
want the .cbp file as well as the CMakeLists.txt to be under source control in your development branch.
When you run CMake and create build files, you come under no compulsion to stop using
your CodeBlocks project, in situ, as your development environment and somehow
migrate the development environment into the build-files folder. Even
if you instructed CMake to generate a Code::Blocks .cbp file in the build-files,
so that end-users of the package can build it with Code::Blocks, you wouldn't then be tempted to
start using that project file as for your development environment: it's a throw-away artifact of running CMake.
If you want to develop the project with Visual Studio then make a VS project for your development purposes in a normal relationship to
the source tree. Make a CMake project for distribution of the project on your target build system. Forget the incidental
fact that the target build-system is also Visual Studio. Keep the files and targets of your CMake project aligned with
those of your development project to the extent that the CMake project is up to date
whenever you build it. And ensure, of course, that the gating tests you run, for commit, release or whatever, are all run on the CMake build.
If you are not interested in distributing your project and are using CMake merely for
the purpose of generating a Visual Studio project in which to develop it - well that
would be a gratuitously laborious alternative to just developing it in Visual Studio -
but if it's what you want to do you will have to be clear that CMake and Visual Studio cannot both control
the composition of the project. CMake controls it and the VS project is just a CMake artifact. If you want to
add files to the project or change it in any other way then you must do it CMakeLists.txt, then rerun CMake and accept the
VS project that drops out - even if you don't quite like the look of it.
I want to use Aquila DSP to compute MFCC features in my project and trying to make it work.I followed this tutorial but after mingw32-make install on the source code pulled from Aquila's git repo, it generates only libAquila.a in lib folder. I tried changing my project's include and library dependencies using these generated files after install. Also tried adding FindAquila.cmake and tried building my project with cmake for VS 2012, still no luck. Keep getting "aquila/global.h" no such file or directory when I try to include "aquila/global.h".
I also tried building Aquila with cmake for VS 2012 and able to compile it and it generates .lib files as well, but not sure how to proceed with that.
If anyone knows how to make it work, it will be great help.
So, I made it work with Visual studio 2013. Now what I am doing is I am building Aquila with both Mingw and with VisualStudio. Mingw gives required include files and visual studio build gives required .lib files. I am building Aquila in VS 2013 with configuration type static lib (project properties >> General >> Configuration type) for both debug and release configuration and then I build the project.
For Mingw, first I use cmake GUI with mingw cmakefiles configuration and then run mingw32-make install in the build directory, which will put the include, lib and share files in the installation directory( usually C:\\Programme files\\Aquila.
Now I create a Folder Aquila and put include and share from above path and create a new folder lib with two subfolder debug and release. Here I put two .lib files in each folder (aquila.lib and Ooura_fft.lib) (debug libs in debug and release libs in release folder, they will be VS build folder). Once this is done, in my project setting, I add Additional include directories under C++ >> general, Addiotnal library path under linker >> general and names of libraries under linker >> input for both bebug and release configuration. After doing all these things, now the library works with my project.
While my primary domain of expertise is not Visual Studio 2015 setup / project configuration, I have experienced troubles on loading / configuring ZeroMQ project.
How to proceed correctly on loading a ZeroMQ Project?
Observed errors:
current build on github and even old "stable" versions cause cmake errors
ZeroMQ Installer does not support Visual Studio v14
Instructions would be awesome, as it seems that there is no other source of documentation for this situation on the internet.
Had the same problem a while ago. Here is what I did to solve this:
Download the right ZMQ version
The "download link" provided on the ZMQ website seems outdated.
To really get the current version you would have to use Git:
git clone https://github.com/zeromq/libzmq.git
Build with Visual Studio 2015
The repository comes with a pre-build Visual Studio project. You can find it in ...\libzmq\builds\msvc. To build for Visual Studio 2015 cd into vs2015 and open libzmq.sln.
You can choose if you want to compile static or dynamic libraries: DynRelease or StaticRelease for either Win32 or x64.
After that, run Build > Build solution to compile everything.
Setup project to use compiled libraries
After you created your project, go to the project's properties:
C++ > General > Additional Include Directories should point to the include path of the repository. If you want to use C++ style some additional files have to be placed in this directory. Alternatively you can take a look at https://github.com/zeromq/zmqpp.
Linker > General > Additional Library Directories should point to the built libraries. They should be located at ...\libzmq\bin\x64\Release\v140\dynamic\.
Linker > Input > Additional Dependencies should contain the name of the library you want to use. The default should be libzmq.lib, otherwise you will find the name in the bin directory.
The program depends on the libzmq.dll file you just built. This file has to be placed within your project's build directory. To achieve this, you can add the following command to Build Events > Post-Build Event > Command Line:
copy /Y "...\libzmq\bin\x64\Release\v140\dynamic\libzmq.dll" "$(OutDir)"
This will copy the .dll file to the destination directory on every build if it's missing.
Hope this helps =)