I'm trying to create a vc++ project that will link several libraries together, without first compiling anything.
I created an empty project, added Additional Dependencies in the Linker options, but when I try to build it I get the following:
1>------ Rebuild All started: Project: sde-mix-mt, Configuration: Release x64 ------
1>Build started 2/6/2013 11:32:49 PM.
1>_PrepareForClean:
1> Deleting file "x64\Release\sde-mix-mt.lastbuildstate".
1>InitializeBuildStatus:
1> Creating "x64\Release\sde-mix-mt.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>FinalizeBuildStatus:
1> Deleting file "x64\Release\sde-mix-mt.unsuccessfulbuild".
1> Touching "x64\Release\sde-mix-mt.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.04
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Although it says Build succeeded it didn't actually build anything (check the time elapsed).
Related
Is there any way to get the embedded make in VS2015 to show why it is rebuilding a particular item?
I have a solution with many sub-projects. When I rebuild I get:
1>------ Build started: Project: ProjX, Configuration: Release Win32 ------
1> ProjX.vcxproj -> [yadda yadda]\Build\Release\ProjX.dll
========== Build: 1 succeeded, 0 failed, 33 up-to-date, 0 skipped ==========
This is repeated each time I build, so something has a screwy time/date stamp, but what? How can I debug this. (Yes, it is not a real problem - but just annoying.)
I have a Win32 project and I needed some resource files. Specifically I have a Main.rc:
#include "Resources.hpp"
IDI_APP_ICON ICON "myappicon.ico"
and a Resources.hpp:
#define IDI_APP_ICON 101
My dir tree is:
├───res
│ myappicon.ico
│ myProject.rc
│
├───src (the files below are just samples except Resources.hpp)
│ a.cpp
| a.hpp
| b.hpp
| b.cpp
| Resources.hpp
Everything is encoded as ANSI.
When I try to build my project from visual studio I get this error:
1>------ Rebuild All started: Project: myProject, Configuration: Debug Win32 ------
1> TrayIcon.cpp
1> MainWindowData.cpp
1> PopupMenu.cpp
1> Main.cpp
1> KbdHook.cpp
1> Generating Code...
1>
1>..\..\res\myProject.rc(3): error RC2135: file not found: IDI_APP_ICON
1>
1>
1>..\..\res\myProject.rc(4): error RC2135: file not found: "MYAPPICO.ICO"
1>
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
I use Visual Studio Ultimate 2013.
What is the problem here? I can't think of anything?
Update:
I changed the myProject.rc encoding to Unicode and it works. Okay, what's going on here?
And I don't want it to be Unicode. Isn't there any possible way to have it as Utf-8 or ansi??
TLDR; devenv appears to build dependencies with whatever config/platform was last selected in the GUI, rather than what /projectconfig says. Ideas?
I have a Visual Studio 2012 solution that builds debug & release, win32 & x64. It has two projects
"common" produces a static library
"foo" produces a dll, and links with common.lib
Both projects output to $(SolutionDir)$(Configuration)_$(Platform), e.g. myTest/Release_Win32 so I can easily swap between configs.
The project foo depends on common, and when I explicitly build foo in the full GUI it properly builds common first, for whichever configuration/platform I'm currently targetting.
However, If I run the command line
devenv.exe myTest/myTest.sln /project foo /projectconfig "Release|x64" /build
Then it will fail because it can't find common.lib when linking. Indeed, there's no myTest/Release_x64/common.lib, but there IS myTest/Debug_Win32/common.lib. I can verify this is caused by that devenv command, it re-appears after removing all the directories.
It appears devenv is trying to build common as a dependency, but failing to specify the projectconfig and falling back to the default Debug & Win32.
I can work around this by manually building common before attempting to build foo, but I'd prefer it to happen automagically. Has anyone else encountered this, or have a workaround/solution?
Here's a solution that demonstrates the problem, and how I created it:
http://beanalby.net/stackExchange/vsDepends.zip
created "common" as Static Lib with new solution
created "foo" as Console App in that solution
added $(OutDir)common.lib as Additional Dependency under Linker/Input for all configurations on foo
marked "foo" depends on "common"
exited visual studio, saving projects & solution
running devenv myTest/myTest.sln /project foo /projectconfig "Release|x64" /build produces:
C:\Users\jason\Desktop>devenv myTest/myTest.sln /project foo /projectconfig "Release|x64" /build
Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.60610.1.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: common, Configuration: Debug Win32 ------
1>Build started 11/15/2013 13:15:22.
1>PrepareForBuild:
1> Creating directory "C:\Users\jason\Desktop\myTest\Debug\".
1>InitializeBuildStatus:
1> Creating "Debug\common.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> stdafx.cpp
1>Lib:
1> common.vcxproj -> C:\Users\jason\Desktop\myTest\Debug\common.lib
1>FinalizeBuildStatus:
1> Deleting file "Debug\common.unsuccessfulbuild".
1> Touching "Debug\common.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.52
2>------ Build started: Project: foo, Configuration: Release x64 ------
2>Build started 11/15/2013 13:15:22.
2>PrepareForBuild:
2> Creating directory "C:\Users\jason\Desktop\myTest\x64\Release\".
2>InitializeBuildStatus:
2> Creating "x64\Release\foo.unsuccessfulbuild" because "AlwaysCreate" was specified.
2>ClCompile:
2> stdafx.cpp
2> foo.cpp
2>LINK : fatal error LNK1181: cannot open input file 'C:\Users\jason\Desktop\myTest\x64\Release\comm
on.lib'
2>
2>Build FAILED.
2>
2>Time Elapsed 00:00:00.56
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
If you open Visual Studio, change the platform/config to anything else, and exit (it won't ask to save), then common will build as THAT platform/config.
This happens with both the VS2012 x64 Cross Tools Command Prompt and VS2012 x86 Native Tools Command Prompt.
Confirming Hans Passant's comment, The docs for devenv say:
Note
For build-related tasks, it is now recommended that you use MSBuild
instead of devenv. For more information, see MSBuild Command-Line Reference.
Using MSBuild instead as
MSBuild.exe myTest/myTest.sln /t:foo /p:Configuration=Release;Platform=x64
lets it get the platform & config properly. This Q/A shall serve as a warning to those still using devenv on the command line. Repent & switch!
I create a simple Win32 projects, edit the configuration and add new platform configurations (x64). I then batch rebuild my project and I get this output:
------ Rebuild All started: Project: Skribe, Configuration: Release x64 ------
main.c
Generating code
Finished generating code
Skribe.vcxproj -> D:\Dev\Skribe\Build\VS2010\Solutions\..\..\..\Output\Bin\x64\Release\Skribe.exe
------ Rebuild All started: Project: Skribe, Configuration: Debug x64 ------
main.c
Skribe.vcxproj -> D:\Dev\Skribe\Build\VS2010\Solutions\..\..\..\Output\Bin\x64\Debug\Skribe.exe
Skribe.vcxproj -> D:\Dev\Skribe\Build\VS2010\Solutions\..\..\..\Output\Bin\x64\Debug\Skribe.exe
------ Rebuild All started: Project: Skribe, Configuration: Release Win32 ------
main.c
Generating code
Finished generating code
Skribe.vcxproj -> D:\Dev\Skribe\Build\VS2010\Solutions\..\..\..\Output\Bin\Win32\Release\Skribe.exe
------ Rebuild All started: Project: Skribe, Configuration: Debug Win32 ------
main.c
Skribe.vcxproj -> D:\Dev\Skribe\Build\VS2010\Solutions\..\..\..\Output\Bin\Win32\Debug\Skribe.exe
========== Rebuild All: 4 succeeded, 0 failed, 0 skipped ==========
The debug x64 build outputs the exe creation message twice and I cannot figure out why. This worries because of a related question I asked where a rebuild actually fails but a clean/build succeeds.
Does anyone know why the extra message is shown? I've done nothing else other than create a solution, exe project, add x64 configuration and batch rebuild.
Trying to compile my simple Qt app in visual studio with the VS-addin for Qt, I receive the following error:
1>------ Rebuild All started: Project: XXXXXXXXXXXXX, Configuration: Release Win32 ------
1>Build started 5/05/2012 6:57:33 PM.
1>_PrepareForClean:
1> Deleting file "release\XXXXXXXXXXXXX.lastbuildstate".
1>InitializeBuildStatus:
1> Touching "release\XXXXXXXXXXXXX.unsuccessfulbuild".
1>CustomBuild:
1> MOC XXXXXXXXXXXXXMainWidget.h
1> moc: Too many input files specified
1> Usage: moc [options] <header-file>
1> -o<file> write output to file rather than stdout
1> -I<dir> add dir to the include path for header files
1> -E preprocess only; do not generate meta object code
1> -D<macro>[=<def>] define macro, with optional definition
1> -U<macro> undefine macro
1> -i do not generate an #include statement
1> -p<path> path prefix for included file
1> -f[<file>] force #include, optional file name
1> -nn do not display notes
1> -nw do not display warnings
1> #<file> read additional options from file
1> -v display version of moc
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 1.
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.05
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
What's the deal? I googled it, and the issue appeared to be a bug in 1.1.7. The solution was to rejigger the includes in the VS project. That said, I would prefer to stay with 1.1.10 - it is only a month old and I am sure that the issue is elsewhere.
This can happen if you have spaces in your filenames or paths.
There might be workarounds with some form of quoting, but the most sane (IMO) way of dealing with this is to simply avoid using spaces in your project path and filenames.