Does anyone know how to use the command line compiler ('cl' and 'link') in Visual C++ to build a project? We are more used to 'make' and 'gcc' here, but were recently moved to Visual Studio. I suppose we could use nmake, but I'm hoping for some information regarding using 'cl' and 'link' (as in compiling without a .sln file).
something along the lines of
create object files
link object files to create executable
is what we want, but I just can't seem to make it work using the command line parameters. Help please?
As I tend to always say, anything Microsoft related can be found on MSDN and a quick trip to google.
cl.exe is documented here: http://msdn.microsoft.com/en-us/library/ms235639%28v=vs.100%29.aspx
It's pretty simple just enter the directory of cl.exe and write in the cmd.
cl.exe /? and then it will list all the available flags.
You need to get 2 Files in you Path:
vcvarsall.bat
cl.exe
vcvarsall.bat is a shellscript which is responsible to determine on which architecture you're running on and includes several folders into your path which the cl compiler needs. on my pc this script resides under C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC
cl.exe is the compiler itself and on my pc resides under C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin
i simply declared a environment variable VC_HOME : C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC and included in the Path %VC_HOME%;%VC_HOME%\bin;
now when you open the shell, at first run vcvarsall.bat and then you can say: cl MyProgramm.cpp
Edit: sorry, didn't notice the 'without .sln' part. Ignore this answer please. I'm leaving it in place for others that may actually need this but it's not an answer to the original question.
If you just want to build a solution/project file (that is, most of your build settings are already defined in your project file), you can use devenv.exe to build the solution/project for you - this is probably the simplest way of doing a build from the command line.
For example:
devenv.exe myapp.sln /Rebuild "Release|x64"
cleans & builds the myapp.sln solution in the Release|x64 configuration.
If you run
devenv.exe /?
command, it gives you all command-line options. You can use devenv to build only a specific project in the solution by using the `/project' switch.
If you need more flexibility (and you're willing to spend a lot of time writing the right script), you can use nmake to build from the command-line, but I don't know that well, so I can't give useful advice.
Related
We have set the parallel execution count to 1 so that all the projects will build one after other.In the Visual Studio settings.
With below command from Devenv.exe we are able to compile the solution correctly.
call vcvarsall.bat x86_amd64
devenv /Build "Release|x64" "w:/Frameworks/Frameworks.sln"
But with MSBuild, with below command, the solution is failing to compile, when I cross check the log, the order of compilation of projects is not correct, not taking from solution file.
call vcvarsall.bat x86_amd64
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" "W:\Frameworks\Frameworks.sln" /t:build /fl /flp:logfile=Frameworks.log;verbosity=normal /p:Configuration=Release;Platform=x64 /m:1
Any suggestion, how to fix set msbuild to compile only from order mentioned in solution file.
Open your solution in VisualStudio, on the solution explorer right click the solution name and look for "Project Dependencies..." and/or "Project Build Order..."
The UI is self explanatory, so configure as required, save all and try the MsBuild command again.
I want to build many c++ projects in Windows 7,
however building them one by one seems fantastic.
Then, I thought to write NMAKE file manually and run some script,
but it seems also troublesome because I have to write many NMAKE files.
So I want to know is it possible to generate NMAKE file automatically from Visual Studio 2010.
Starting with Visual Studio 2002, there is no longer a way to export your VC++ project files to a Makefile. (That option existed up until VC++ 6.0 but was removed.)
As of VS 2010, the build process for VC++ projects is the same as any other projects: there is a solution file and a set of project files, both of which are recognized by MSBuild as inputs. MSBuild take care of the dependency resolution, build ordering, etc.
The only significant feature that you lose building inside the IDE is parallel builds. If that's your concern, you can run the msbuild command on your solution file and pass in the /m parameter to specify how many simultaneous builds it should attempt.
As far as I know, no one has built any kind of tool or plug-in to parse the .vcxproj files and spit out a makefile, though the file format is pretty well documented XML, so you could always write one yourself. Otherwise, if you really need makefiles for some reason, you'll have to craft them by hand.
You can use MSBuild to build a Visual Studio solution or project from the command line.
Convert it to CMake https://stackoverflow.com/a/9387350/525578
Generate using NMake or Jom generator of the CMake
I'm using CMake to build ParaView with Visual Studio Express 2010. I'm having a problem with the generated solution. The problem is that one of the entries generated for additional dependencies (the MPI libraries) should be semi colon separated but it is space separated. The result of this is that the linker generates a lot of errors when building the project.
This is the error message:
LINK : fatal error LNK1104: cannot open file 'C:\Program Files (x86)\MPICH2\lib\mpi.lib C:\Program Files (x86)\MPICH2\lib\cxx.lib'.
In the project configuration there's an entry that reads:
C:\Program Files
(x86)\MPICH2\lib\mpi.lib C:\Program Files (x86)\MPICH2\lib\cxx.lib
But there should be two entries separated by a semi-colon:
C:\Program Files (x86)\MPICH2\lib\mpi.lib;C:\Program Files (x86)\MPICH2\lib\cxx.lib
I tried to fix it by correcting the reference to the libraries manually project by project, but it is taking way too long.
I think this could be fixed at the CMake level, or at Visual Studio level (by fixing the additional dependencies entries for the whole solution) but dont really know how to do any of those things. I'm not familiar enough with CMake's architecture to pinpoint what I need to change. How can I solve this?
Check your CMakeLists.txt for a line with TARGET_LINK_LIBRARIES. If this command uses quotation marks inside the brackets, try removing them. For example, if you have:
TARGET_LINK_LIBRARIES(MainExe "${lib1} ${lib2}")
change it to:
TARGET_LINK_LIBRARIES(MainExe ${lib1} ${lib2})
If this doesn't help, you should probably post the CMakeLists.txt in your question.
This looks like a bug in the FindMPI module. The quickest way to fix this is to edit the CMakeCache.txt in the root of your build tree. You will need to edit the MPI_LIBRARY and MPI_LIBRARIES entries to use semicolons instead of spaces.
I work with the same Visual Studio projects on multiple computers (work/home) using Dropbox to sync between the two. Because VS creates some extra large files, I used to remove the following before uploading to Dropbox:
Files = .pdb, sdf, .ilk .exe .tmp
Folders = ipch/, Release/, Debug/, GeneratedFiles/
Everything worked fine in the past, however, some problems have now risen.
I receive the following errors:
Moc'ing CodeInterface.h...
1> The system cannot find the path specified.
1> Moc'ing ThreadWorker.h...
1> The system cannot find the path specified.
1> Rcc'ing StreamAnalyser.qrc...
1> The system cannot find the path specified.
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 3.
So, I think I may have to create a new Visual Studio project and import the classes manually. So my question are:
Best practices for working with projects on different computers?
What files can be deleted (for uploading to Dropbox)?
Does Visual Studio have some sort of 'global settings' (or something similar to 'workspace' used with Eclipse)? How do I set these settings to prevent trouble when working on different computers?
Thanks!
I am not familiar with dropbox so I can't speak for what you do currently
What I like to do is to use a distributed versioning system (I use git) to look after the source code only. I use a .gitignore file to not version any object code and visual studio project files and the like. I can then clone these projects (with their versioning) easily across to any computer I like - including test branches that I might idly play with when coming home on the train on my laptop.
In my experience visual studio project files are a pain because different versions do not play nicely with eachother (1 computer has vs2005 and another has vs2008). To overcome this problem I like to use cmake as my build system (I include these in my git repository too). Cmake is a 'meta-build system', in that it generates the visual studio, or eclipse, or autotools make files for you, and then you do the native build in VS or Eclipse or with make.
Using these two packages together means that you can copy properly versioned controlled source code between any computer (including linux, mac and windows) and then build the source code natively on that computer, using whatever IDE you have installed on that computer.
"moc" is a Qt executable that pre-processes .h files. It's invoked by the MSVS build system. However, if it would be missing, you'd get the "The system cannot find the path specified." error after "Moc'ing CodeInterface.h".
My bet therefore is that MSVS can't find your Qt implementation. I'm not entirely surprised; the Qt4 build system and its integration with MSVS didn't strike me as very robust ir reliable when I tried to install it recently.
I would recomend you use svn with anksvn. Subversion is built to manage working on diffrent computers and has the added bonus of version controll.
In your case, you may delete files but not directories, i.e. GeneratedFiles\Debug and \Release should stay. If you look onto your h files, they do moc-ing and uic-ing as custom build step, and there is no path checking code in that events.
"$(QTDIR)\bin\moc.exe" -DQT_NO_QT_INCLUDE_WARN -DUNICODE -DWIN32 -DQT_THREAD_SUPPORT -DQT_CORE_LIB -DQT_NETWORK_LIB -DJSBRIDGEAPI_LIB -D_WINDLL -I".\GeneratedFiles\." -I"$(QTDIR)\include\." -I".\GeneratedFiles\$(ConfigurationName)\." -I".\." -I"$(QTDIR)\include\QtCore\." -I"$(QTDIR)\include\QtNetwork\." -I"$(QTDIR)\include\QtWebKit\." ".\apisignalemitter.h" -o ".\GeneratedFiles\$(ConfigurationName)\moc_apisignalemitter.cpp"
So - adding dirs .\GeneratedFiles\$(ConfigurationName)\ may solve your problem.
Also, check if $(QTDIR) defined.
UPD - make sure you have QT installed on both machines in some place
I'm usually using SVN for version control and a qmake pro file for project settings. You can use qmake to create a Visual Studio project file from the pro file and work with Visual Studio, or create Makefiles and other project files on Windows, Linux and Mac, so it's a quite portable solution.
I'm currently working on a console application that will pass a vcxproj file and compile it using GCC. Unfortunately, I've come up against a whole load of problems pretty much instantly.
I notice a bunch of directory shortcuts such as:
VCTargetsPath
VCInstallDir
SolutionDir
ProjectDir
UserRootDir
and so on.
Where does MSBuild get these values from? I assumed they were environment variables set up for the MSBuild process (afterall known environment variables are addressed the same way, ie "$(...)"). This was a bad assumption so I'm left wondering exactly how I get at these. Has anyone any idea on this?
Any info would be much appreciated :)
The MSBuild executable (and dependent DLLs) processes those properties the same way it processes any other property in the build file. In this case, they're simply predefined properties that it looks for explicitly.
If you really want to dig into it, open up the Microsoft.Build.dll in Reflector and look for the Microsoft.Build.Construction.SolutionProjectGenerator.AddGlobalProperties(...) method to get an idea of how it's handling some of the well known properties.
As an additional note, make sure you fully navigate down Import directives and handle overwriting of property and item values with each Import. There's a number of properties and items that are part of a Visual Studio build that are not always necessary for your code to compile correctly.
I believe that these are tied to Visual Studio macros: MSDN
Some of them are defined by the location of your files
SolutionDir - the directory containing the solution (.sln) file including this project
ProjectDir - the directory containing the project file (.vcproj, .vcxproj)
Others are defined by the location of the MSVC install
VCInstallDir - where the Visual C portion of Visual Studio is installed. ie. C:\Program Files\Microsoft Visual Studio 8\VC
and so on, and would be internal to msbuild based on what you loaded.