Why do you have to build under release configuration, followed by another build of same project in debug configuration in VS2010 C++ to be able to have the debug see updated code?
You don't have to. You only have to build the configurations which you want updated. That is, if you change your code and want to have Debug "see" the updated code, just build Debug. You don't have to build Release.
Of course, then your Release build will not "see" the new code until you build it again.
If you're asking why they have to be built separately - because the code generated by each of these settings is fundamentally different, so there's now way to "reuse" it somehow.
Because each build links to different core libraries, uses different compiler/linker settings, creates different assembly code, and hence different executables, the release one probably more optimized. Btw there is a Batch Build menu item under the Build menu allowing to build everything with one click.
Related
Motivation
PreBuild to disable compilation of redundant projects for faster compilation cycle.
Background
I have a VS15 ALL solution that contains many projects.
I have a single project, PreBuild, that all the other projects are dependent on, meaning, this PreBuild compiles first.
In addition, we also have a PostBuild project that do some more work once binaries are ready.
All projects are configured to build in Release mode (which is desired).
When a team member wants to release some binaries, he hits F7, Build Solution.
Now, the PreBuild, activates a separate dedicated process that calculates which projects should be released. The nature of the calculation is irrelevant to this discussion.
Problem
Out of the many many projects, it is often the case that only a few projects needs to be released. However, once the PreBuild process is done, ALL the projects are will compile which is very time consuming.
Question
Is it possible, after a solution build had started, to change the released projects?
Suggested unwanted approaches
A developer handpicks only the relevant projects and only build those.
PreBuild Kill & Revive. Once desired projects are calculated, PreBuild kills the VS15 process and activate a cmd compiling only the relevant projects.
Suggested approach
Change file ALL.sln and remove the the unwanted projects.
This would work had I changed that file prior to the process start but I'm not sure it would work if this change occurs during the process.
The simplest way I can think of, while still keeping most of the current infrastructure in place: have a dedicated project which invokes the release build (by calculating dependencies and invoking msbuild) and configure VS so it can be select just that project for a build. All from within your ALL.sln so the rest of the features remain. Steps:
Get rid of the PreBuild/PostBuild projects. I assume the PostBuild you mention is also meant for the actual release builds; if not just leave it there. Note by not requiring all projects to depend on the PreBuild project you already got rid of one maintainance burden.
Add one single project which will do the release building, say ReleaseBuild. Such name is also better than having PreBuild/PostBuild projects since it clearly states the intent of the project. A Makefile project is suitable, though technically it could be as simple as an msbuild file with just one Build target. Configure the build command line to do whatever is needed, i.e. figuring out what to build then build. For the sake of an example: say you use Powershell to do this you would configure the build commandline to be
Powershell -NoProfile -File BuildRelease.ps1 $(Platform)
and BuildRelease.ps1 contains something like
$projectsToRelease = CalculateMyProjectsForRelease()
$platform = $Args[0]
$projectsToRelease | %{& msbuild $_ "/p:Configuration=Release;Platform=$platform"}
In Configuration Manager add an extra Configuration called Deploy or so. This will be used to select what to build: you probably have Debug and Release configurations now already. Those stay in place, and are simply used to build everything. The idea is this extra configuration will take care of building the actual release. This is fairly consistent with the standard way of working in VS and easy to discover and understand for newcomers. Using the checkboxes, make it so that when the Deploy configuration is selected only the ReleaseBuild is built and none of the others whereas when Debug or Release is selected the ReleaseBuild project is not built. Looks like this:
To build a release, select Deploy from the configuration drop down menu in the VS toolbar and hit F7 (or whatever way you use to invoke Build Solution). Any build errors/warnings will be parsed and shown as usual in the Error List.
This is also easy to extend: suppose you only have a couple of release build versions just add more configurations like DeployA DeployB DeployC and adjust the build command line for them.
I'm trying to automate our main project build (C++) via Team Build system (TFS 2013).
However, I see that a couple of projects are always built, even if no code change has occurred, while this does not happen using VS2013 on my development machine. This would cause some headache since binaries would always be generated and sent to test team even if not really modified.
Enabling "diagnostic" verbosity in build output, I see that the two project exhibit different behavior.
In the first project the log says that all .cpp files are rebuilt because the .PCH file has been modified (although no change happened). I could try disabling the PCH but would really avoid it if possible. Besides, not going to the root cause of the error would leave an open door to the error representing again and again.
In the second project, we have a pre build step that generates a .h file. However, prebuild steps should not run if no change in the code has been detected (https://msdn.microsoft.com/en-us/library/42x5kfw4.aspx), so happens indeed on my development machine. On the build machine, instead, the prebuild step is executed, the .h is generated and this forces a complete rebuild.
In the team build settings I have "Clean workspace=false", "Clean build=false". I also tried "/p:IncrementalBuild=True" in MSBuild settings, but this did not fix the issue.
Note - I already looked at Visual Studio Rebuilds unmodified projects and VS2010 always rebuilds solution? before posting.
According to your info about project2, the pre build step executed on the build agent and not executed on your local machine. There must be something different with your local build environment and build agent environment. This may be the root cause.
Suggest you to double check it and make sure the environment is the same with each other. And try it again.
Is there a way to understand if a C++ Project has been Build previously in Eclipse?
I have to rebuild some projects sometime because I can not tell if it has been build before. And this process takes a lot of time.
Yes, you will get to know. when you click build and it was successful, and later you make some changes, and get error, you can go back to your last build configuration. You also can build it automatically, when you save.
I have a C/C++ solution comprised of several projects in VS2010. The start-up project is where main() locates and it will generate .exe file, while the others are core algorithms which will generate .dll files. When I debug the whole solution, sometimes it cannot go into the .dll projects but after rebuilding the whole solution, the problem can be temporarily solved; However after building one or more times, the problem returns.
Currently I have to rebuild the whole solution every time I modify the code, but it's so bothering. Is there any way that I can avoid such a problem?
It is happening only in the case when some project in your solution is changed or the .exe present in release or debug directory is different from the code. So, make sure like you are building each project successfully after modifying it.
And it is always good to debug in DEBUG mode to get exact result.
Everal things you could try: Make sure all projects which need to be rebuilt after a change indeed are. So make sure the project dependencies are set correctly and that the startup project is the exe project.
As second option, you could allow the debugger to show source even if it does not match the code exactly (look for something named "source files must match original exactly" or similar in Options->Debugging->General). Be aware that it might indeed happen that your changes are not reflected in the program if this is needed.
When I try to batch build my project, I encounter this error while I have enabled the clr runtime support.
My project can run with no problem and I only receive this error when I try to make a batch build.
I have made a lot of searched in google but most results are about enabling the clr option.
I'd like to know how I can fix this problem.
This is the kind of problem you'll run into when you make project setting changes while you are debugging your project. Settings are stored per configuration. A common mistake is to make the change for the Debug configuration but forgetting to make the same change for the Release configuration. Kaboom when you then try to get the Release configuration built, as would happen when you use Batch Build.
Go slower. Project + Properties, Configuration Properties, General. Note the combobox labeled "Configuration" in the upper left corner. It probably now says "Active (Debug)". Change it to "Release". And note how the "Common Language Runtime support" setting changes as you flip back and forth. Make them the same, /clr. Use Build + Configuration Manager to make the Release build the default configuration and use Build + Build to build it. Test it.
There might be other settings you've changed that need to be corrected for the Release build as well.