I have a big C++ project and I need to do many steps in the building phase because I am building an application that is compatible with both 64 and 32, I have three projects:
proj1,Porj2,Proj3
and I need to do the following:
Exclude a cpp File from proj1 (32bit version)
Include a cpp file to proj1 (64bit version)
build proj1
build proj2
Execute output of proj2
Exclude a cpp File from proj3 (32bit version)
Include a cpp file to proj3 (64bit version)
Build proj3
Rename the exe that was built from proj3
Exclude a cpp File from proj1 (64bit version)
Include a cpp file to proj1 (32bit version)
still there are some other steps ... I was doing that manually and its frustrating, I found the I need to use MSBUILD but is it used for building native code ? and how can I perfrom these tasks ?
-Excluding and Including cpp files into projects
-Building proj
In Visual Studio 2010 and later, C++ projects use MSBuild.
Rather than excluding or including files based on the configuration, it would be simpler to use a preprocessor directive to conditionally compile the contents of the file. E.g., wrap the entire contents of the file in:
#ifdef MY_32BIT_BUILD_MACRO
// Source file contents here
#endif
And likewise with a macro for 64-bit builds. When using Visual C++, you can use the _M_IX86 and _M_X64 predefined macros to detect whether you are compiling for x86 or x64, respectively.
Alternatively, you could add a Condition property to the ClCompile item for the particular source file in the project file, and have it only included in the build when certain properties are set. I think that conditional compilation within the source file is a better option, though, unless you have complex rules that you need to use to determine whether to include a file or not.
In your solution, you can set project dependencies to ensure that one project is built before another. Right-click the solution, select Properties, and browse to Common Properties -> Project Dependencies. Dependencies can also be specified in a project file.
You can execute the output of a build by using a post-build task. Right-click the project, select Properties, and browse to Configuration Properties -> Build Events. The Post-Build event can be used to execute a command when the build has completed.
Rather than renaming an executable after build, it's easier to just have the build produce an executable with the right name. In the Project properties, under Configuration Properties -> General, the Target Name property can be used to set the name of the primary build output.
Related
I am developing a system of build scripts for CMake and have an issue with wanting to have intermediate CMakeLists.txt files appear in the IDE for easier search and edit.
I have a main CMake file that includes a directory that includes several subdirectories for libraries.
CMakeLists.txt
--- SubProjects:
-------CMakeLists.txt
-------ProjectAFolder:
----------CMakeLists.txt
-------ProjectBFolder:
----------CMakeLists.txt
-------ProjectCFolder:
----------CMakeLists.txt
In the SubProjects folder, the CMakeLists.txt is very simple and just includes the subproject folders one after the other:
SET(SUBDIRECTORIES ProjectAFolder
ProjectBFolder
ProjectCFolder )
foreach (subdirectory ${SUBDIRECTORIES})
add_subdirectory(${subdirectory})
endforeach ()
However, when I generate this in XCode or Visual Studio, the IDE does not include the intermediate CMakeLists.txt file anywhere because it does not belong to any individual library or executable target. What is the best way to include this somewhere so it appears in an IDE?
Depends on where you want the file to show up, since it doesn't belong to any target. You can simply add it to any existing target (just as you do with source files) or you can create a new custom target.
add_library(AnyExistingTarget <other source files> SubProjects/CMakeLists.txt)
Or create a custom target:
add_custom_target(MyIntermediateCMakeFiles SubProjects/CMakeLists.txt)
For Visual Studio, you could also use the built-in support for cmake. It will display the source tree in the IDE without any extra work.
We have two projects A and B. B referes to A. We created two targets for MSBuild to compile where difference is only in output path (it is separated file, not projects csproj's). Immidiate folder for both project are standard I mean obj folder.
We run first target (MSBuild from command line with /t switch) - everything compile ok. We didn't change anything in cs but we changed output path and compile. In that case A is not recompiled but B is fully recompiled. So in output path we had A with the same version but B versions are different.
Do you know why B project is recompiled?
EDIT
After some research it looks like MSBuild takes output path as part of cache hash (this file: obj\Debug\CoreCompileInputs.cache).
We call MSBuild like this:
msbuild mysolution.sln /p:OutputPath=c:\mydir
and csprojs are standard VS2017 csproj.
I have a visual C++ project for a DLL and a setup project for it. In the installer i've added the content files of my project.
Is there a way to add a file as a content file depending on if you are compiling debug or release? I want to include boost_date_time-vc100-mt-gd-1_51.dll if I compile under debug and boost_date_time-vc100-mt-1_51.dll if I compile under release.
My additional deps looks like this
Shell32.lib;libzmq.lib;log4cxx.lib;boost_date_time-vc100-mt-gd-1_51.lib;...
Under additional library directories i've added the path to all these .lib files which also contains their respective .dll files
I've tried the following with no success...
Added a Custom build step to run before build that copies the correct dll files to the OutDir and set the Output of this custom build step to be the dll files.
Conditionally include a content file by manually editing the vcxproj file. If configuration was release mode I would set the non-debug version as deployment content and the debug version to false and vice versa for Debug mode. This looked something like this,
<ItemGroup Condition="'$(Configuration)'=='Release'">
<None Include="boost_date_time-vc100-mt-1_51.dll ">
<DeploymentContent>true</DeploymentContent>....
</None></ItemGroup
Neither of these worked however. The second option seemed to always default to debug mode no matter how I built my project.
When you add a dependency, you can add it to one configuration or all configurations:
[This picture is of VS 2012, but 2010 and 2008 look pretty much the same.]
So, you pick the configuration you want to modify at the top-left, then add the library to the additional dependencies. Note that what you add here will be the .lib file associated with a DLL, not the dll itself (the compiler will make the executable depend on the DLL because you link with its .lib file).
I'm using Eclipse Juno for c/c++ under Windows 7. I've created a shared library project and an executable project. I've added the shared library project as a reference in the executable project via:
executable project's properties -> C/C++ General -> Path and Symbols -> References -> check the shared library project
All this works great at compile time, I can include my shared library project's class in the executable project, and use it etc.
However when I try to run the executable project in Eclipse, I get nothing. No error, no console output. After some googling I've discovered a similar issue here:
http://www.eclipse.org/forums/index.php/m/650331/
Apparently adding the shared library project to the executable project in Eclipse, as described above, does NOT also add the dll file to the executable (.exe) file's PATH at run time inside Eclipse. As an analogy with Eclipse for Java: if you have a Java JAR project A and another Java JAR project B, by making a reference from B to A in Eclipse, B's compiled jar file IS added to A's class path when running project A inside Eclipse. I thought it would be similar with Eclipse for C/C++ but apparently it's not.
Sure enough, if I manually take the .exe file and the .dll file, place them in the same folder and run the .exe, everything works ok. Also if I copy the .dll file in to Eclipse's compilation directory for the executable project, I can run the executable project from Eclipse and it's ok.
My question is then, is there a way to have Eclipse add that shared library project's dll file to the run time when I'm telling it to run the executable project? The discussed solution in the post I link to above is to manually add the shard library project's compile directory to the Eclipse's run configuration for the executable project, namely, to add it to the PATH variable there. But I find this cumbersome and not portable, if Eclipse is managing both projects it should be able to pass all that's necessary to the run time.
Well, I've went with the manual adding of the library project's dll to the excutable project's path at run time. I did find a way to make it more portable and project location neutral (i.e. if you move both projects' source folders to another machine, and reopen them in Eclipse there, it should still work):
right click on executable project -> Run as... -> Run Configurations
in the Environment tab click "New..." to add a new environmental variable
Name your variable "PATH" and give it a value similar to this:
${env_var:PATH};${workspace_loc:/cppAStar/Debug}
where:
${env_var:PATH} is Eclipse's way of saying "get the already existing value of the PATH environmental variable as declared in Eclipse"
the ";" is to separate the exisitng PATH entries from the new one we're about to add
${workspace_loc:/cppAStar/Debug} this tells Eclipse to get the location of the workspace project named cppAStar (here cppAStar is my shared library project) and then the "/Debug" refers to where this particular project creates the .dll file when it's built.
Issues that I couldn't figure out:
the "Environment" tab in "Run configuration" has an option called "Append environment to native environment". I thought that by checking this I'd only need to add the location of the .dll dir in the PATH variable I declare here, and it will be appended to the existing PATH. However I've not managed to make this work, hence the manual re-adding of all the existing PATH before appending the new value
Unfortunately that solution does not work for the debugg configuration. See Bug 338420 -Launch configuration's Environment tab variables are not passed to the gdb process itself.
Is there a way to solve this problem for debugging? I mean except from doing post-build steps like:
cmd /c copy "${BuildArtifactFilePrefix}${BuildArtifactFileName}" "${WorkspaceDirPath}\bin\"
i have some visual studio projects which depend on other projects, which have different configurations.
example:
Project MyProject (Configuration: Release)
References:
Project LibA (Configuration: Release_DontLink)
Project LibB (Configuration: Release
Building using Visual Studio works correctly as the Configurations to be used for the different projects are stored inside the solution file.
But when i use msbuild to build MyProject, it builds the Release configuration of LibA, which is incorrect. Since both LibA and LibB are used by numerous other Projects, i cant change those configurations, i only have control over MyProject.
Is there any way to build MyProject using MsBuild without changing the LibA and LibB projects?
Possibly related question: Configuration for ProjectReference in MSBuild, however i did not fully understand the answer, and i think it would require me to change LibA/LibB
On the solution level (i.e: MyProject.sln), open the property pages and set the Release configuration to build Release_DontLink configuration for project LibA. If you don't have control over the sln file, you should be able to create a copy of it (i.e: MyProject.Release.sln).
Then build the solution with:
msbuild MyProject.sln /p:Configuration=Release
Alternatively (not even remotely a best practice), after building MyProject build LibA while overriding its OutDir property:
msbuild LibA.csproj /p:Configuration=Release_DontLink;OutDir=..LibA\Release
I just had the same problem and found that the solution config needed to be done for all configured platforms.