Visual Studio puts new files into wrong directory - c++

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.

Related

How to make swapping between Debug/Release less painful in this cross-platform project?

We have a C++ CMAKE project. I work on it under Windows using Visual Studio 2019. My coworkers work under Ubuntu using QTCreator.
Here is what my current steps look like for swapping from a DEBUG build to a RELEASE build:
First set up VTK:
Open the release VTK build folder in Visual Studio and build the "INSTALL" subproject to overwrite the installed debug version of VTK with the release build.
Then set up our project:
Edit my account's PATH environment variable to point to the location of the new sub-project DLLs where Visual Studio will put them. (myProject\lib\analytics\Debug to myProject\lib\analytics\Release)
Without telling Windows where the sub-project's DLLs are, trying to execute the program does not work. Not sure if there's a way to tell Visual Studio to look for the DLLs automatically.
Edit the top-level CMAKE of the project:
SET(BUILD_MODE Release)
set(CMAKE_BUILD_TYPE "RELEASE" CACHE STRING "Sets release build by default")
Open Cmake-GUI and clear the cache, then run "Configure" and "Generate"
If I do not clear the cache, Cmake Gui has consistently used older/incorrect settings resulting in unusual build issues.
Open the project under Visual Studio, changing the build type at the top to my new choice.
Hit "Rebuild" on ALL_BUILD.
With all those steps done, I have managed to swap from a Debug to a Release build.
Is there some way to simplify this process and make it easier to swap between the two?
I am not very familiar with Visual Studio or Cmake, so I'm not sure what functionality I'm missing out on.
There should be no need to change reconfigure the cmake, project when using a multi configuration generator. This of course assumes that the VTK package provides imported targets via find_packag(VTK) that properly work with different configurations. You should be able to verify this by checking the import libraries for different configurations of one of your targets in Visual Studio: there are different import libs for the Release and Debug configurations, you're good to go.
As for enabling your program to find the dlls depending on the confiruation, when using the "Play Button" (Visual Studio Debugger):
You should be able to use generator expressions to modify PATH variable in the environment depending on the configuration.
The following assumes the dlls are located in .../lib/<vtk_component_name>/(Debug|Release) directories.
# should evaluate to "C:/Users/..../buildarea/.../lib"
# Note: it's very likely find_package(VTK) already provides necessary info
set(VTK_BASE_DIR "...")
set(VTK_PATH "")
foreach(VTK_COMPONENT IN ITEMS
data-manager
execution
...
)
# use vtk Release configuration for everything but the debug config
set(VTK_PATH "${VTK_BASE_DIR}/${VTK_COMPONENT }/$<IF:$<CONFIG:Debug>,Debug,Release>;${VTK_PATH}")
endforeach()
set_target_properties(my_exe PROPERTIES
VS_DEBUGGER_ENVIRONMENT "PATH=${VTK_PATH}$ENV{PATH}"
)

Setting up Aquila for my c++ Project in Visual studio 2012

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.

How to set up [ ZeroMQ ] for use in a Visual Studio 2015 Enterprise?

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 =)

qmake: how to remove the dependency of absolute paths?

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.

Building/Running Google Test

I am trying to build and run Google Test but encountered some issues.
Any help greatly appreciated.
I used CMake 2.8 (with UI) to create .sln and .vcproj files in the D:/MyBuild
directory (as mentioned in the README file of google test).
However, when I try to run the .sln file in the MyBuild directory,
here is what I get (image):
Also, here is a screenshot of the CMake which I used to
create .sln files and .vcproj files in the D:/MyBuild directory.
ps. One thing I noticed is that README was giving instructions how
to use non graphical version of CMake (e.g., 2.6) to install
google test, however I used one with user interface - maybe
I did something wrong there?
You appear to have successfully built gtest's libs in Debug mode. However, by default the .sln doesn't contain any executables, so you can't actually run anything.
If you select the checkboxes in the CMake GUI for gtest_build_samples and/or gtest_build_tests and hit "Generate", then the Visual Studio solution should contain some executables.
From memory, these don't build cleanly, but I don't have MSVC 2010 to hand, so I can't be sure.