I'm trying to get absolute control over the output of MSBuild. If I run:
msbuild project.msbuild
or:
msbuild project.msbuild /p:configuration=Debug
I will get the folder:
Debug
If I run:
msbuild project.msbuild /p:configuration=Release
I will get the folder:
Release
The output directory structure I want is the following:
Win32\Debug
Win32\Release
x64\Debug
x64\Release
I first tried OutputPath but nothing happened. Then I tried the following:
<OutDir>$(Platform)\$(Configuration)\</OutDir>
Now I get the compiled binaries in the specified folder but for some reason the old directory structure is created to contain the object files. So if I run:
msbuild project.msbuild
What I end up with is:
Debug (contains object files)
Win32\Debug (contains binaries)
I want everything in the same folder, the one I specified, not the default MSBuild decides upon.
Object files are stored in 'Intermediate' directory.
By specifying OutDir - you specify location of binaries.
To specify location of .obj files you should additionally try specifying IntermediateOutputPath to the desired location of .obj files.
See reference, for example: https://blogs.msdn.microsoft.com/kirillosenkov/2015/04/04/using-a-common-intermediate-and-output-directory-for-your-solution/
Related
Folder structure
~/sandbox/dev
~/sandbox/test
I have main.cpp in dev directory. I compiled the code using --coverage flag to generate code coverage.
Now a.out and main.gcno files are generated.
Now I copy main.cpp, main.gcno and a.out to test directory
When I run the a.out from test directory, the main.gcda file is generated at the dev folder instead of current working directory.
It seems like the path is hardcoded in the binary/gcno.
What changes are required so that the gcda file will be generated in test directory ?
By default, the .gcda files are also stored in the same directory as the object file, but the GCC -fprofile-dir option may be used to store the .gcda files in a separate directory.
https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html
-fprofile-dir tag in GCOV utility
Kind of a late answer - but you can use environment variables GCOV_PREFIX and GCOV_PREFIX_STRIP to direct the .gcda files to some other path.
You do need to copy (or link) the .gcno files and .gcda files to the same directory in order to run gcov, though.
So I have a project structure like this:
/
build/
data/
include/
src/
build.bat
My build.bat looks like this:
#echo off
pushd build
cl -Zi /EHsc ../src/*.cpp /I.. /Fepea1
It produces the executable, great. Now I have some data I have to read from data/ directory. Now the executable is in build/ directory, so I would have to copy it to the root directory or I would have to use relative path (like ../data). But I don't want to do that, cuz I don't know how will I be releasing this project (so I just want path = "data/). In Visual Studio there was a way to specify projects working directory. Can I do this with cl.exe? Or do I need to use relative paths?
You can just run the executable from the data folder.
..\build\out.exe and it will run from the data context.
You can do this using cmd.exe
It is my understanding that CMAKE_CURRENT_BINARY_DIR should point to the directory where binaries for the current CMakeLists.txt file will be placed. However, this doesn't seem to be the case.
Consider this file structure:
CMakeTest
+- CMakeLists.txt
+- main.cpp
CMakeLists.txt
cmake_minimum_required(VERSION 3.2)
add_executable(CMakeTest main.cpp)
message(STATUS "CMAKE_CURRENT_BINARY_DIR = ${CMAKE_CURRENT_BINARY_DIR}")
main.cpp
#include <iostream>
int main() {
std::cout << "Hello, World!";
return 0;
}
On the (Windows) command line, I run the following commands:
md build
cd build
cmake .. -G "Visual Studio 14 2015"
cmake --build .
The first cmake command prints (among other things) the line
CMAKE_CURRENT_BINARY_DIR = X:/dev/projects/CMakeTest/build
So I'd expect the resulting binary file CMakeTest.exe to end up there. Really, however, it is placed in X:/dev/projects/CMakeTest/build/Debug.
Why isn't the binary file placed into CMAKE_CURRENT_BINARY_DIR, but in a sub-directory? And is there any CMake variable that tells me what that subdirectory is?
Edit:
I'm not trying to change the directory where binaries are placed. I'm trying to determine it. The reason is this:
During build, a number of additional resource files are created in the same directory as the executable file. (This part works.) I'd like to use the install(FILES, ...) command to then add these files to the resulting package. So I need to pass the actual path where the binaries are placed to install(FILES, ...).
Variable CMAKE_CURRENT_BINARY_DIR denotes "binary directory currently being processed" by CMake. Usually, this directory and its subdirectories contains build artifacts, like executables, libraries or other generated files.
If you want to control location of executable being built, you need to set variable CMAKE_RUNTIME_OUTPUT_DIRECTORY.
Note, that multiconfiguration build tools, like Visual Studio, for each specific configuration will create subdirectory (named as configuration itself) under CMAKE_RUNTIME_OUTPUT_DIRECTORY. Otherwise, executables created for different configurations would overwrite themselves.
For precise control of per-configuration directory used for built executables, use variable CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG>. (Instead of <CONFIG> name of specific configuration should be inserted, so CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG variable will affect Debug builds).
For just determine directory with executable, use $<TARGET_FILE_DIR:tgt> generator expression (instead of tgt a name of the target created the executable should be used).
Note, that generator expressions can be used only in specific places. E.g., list of files for install(FILES) command can use generator expression, but message() command cannot.
Yes, the executables are often stored at a level below the CMAKE_CURRENT_BINARY_DIR, based on the build type. You can navigate to this directory directly by using ${CMAKE_BUILD_TYPE} (which is typically has value of Debug or Release) by building a full path like:
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_BUILD_TYPE}
I would like to use CMake for a project, but I have the following two requirements:
The final output of the project should be a set of object files (*.o).
The location of the object files is important. I want to select which directory the files are outputted.
Does CMake support this type of behavior? If so, how? Can I do it with move commands after the object file is build?
First create an object library.
Now the problem is that:
Object libraries cannot be imported, exported, installed, or linked.
http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:add_library
I would try to use the install(DIRECTORY ...).
Using the options:
DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} #Probably you have to check more precisely where the object files are built
DESTINATION #it's something relative to DESTDIR, if set, or CMAKE_INSTALL_PREFIX otherwise
FILES_MATCHING
PATTERN "*.o"
A flaw of this solution will be in the output directory name, that will be basically decided by cmake, I wonder if anything can be done in that respect.
I am using a CMake command to install PDB files to enable debugging in a developer distribution of my C++ application. The command is as below:
INSTALL(DIRECTORY ${PROJECT_BINARY_DIR}/Debug
DESTINATION bin
FILES_MATCHING
PATTERN *.pdb
)
Also, I've managed to install the relevant source used to build that developer distribution, in a 'src' folder at the same level, so that my top level distribution folder looks as:
include\
src\
lib\
bin\
share\
doc\
3rdparty\
etc\
How can I let the PDB files 'know' where the source is (I am assuming this is required)? Is there a CMake command that can achieve this? What would be a small example?
I just answered my own similar question, How to get CMake to install PDB files for targets.
Use this install rule to copy the target's PDB file, if it exists, to the target's install location bin directory.
install(FILES $<TARGET_PDB_FILE:${PROJECT_NAME}> DESTINATION bin OPTIONAL)
PDB files store absolute path names to the source files. When not using a symbol server, the only way to ensure some degree of source code relocatability is to use the subst command.
The idea is to use subst to create a drive-letter name (e.g. N:\) for the root of the source tree. Then do your builds from this drive, so that absolute paths starting with N:\ get embedded into the PDB files. When you later need to debug the executable on a different machine, use subst on that machine to get the same absolute paths to the sources. This will enable the PDB files to find the source files.
For example, if you have a file C:\MySources\main.cpp, do the following:
subst N: C:\MySources
N:
run your build
Later, let's say you need to debug on a machine where the same file is stored in D:\Devel\Other\main.cpp. Simply do subst N: D:\Devel\Other and then work from the N: drive there as well.
This answer is largely based on information from this question and the links therein.
You just need to inform Visual Studio where the source is... It will pop up a file browser dialog; just point to the source on your local machine if the paths differ from when it was built.
The PDB file stores the path to the files as they were when the program was compiled. There is nothing you must do to let them know where the source was.