Today is officially my first day with C++ :P
I've downloaded Visual C++ 2005 Express Edition and Microsoft Platform SDK for Windows Server 2003 SP1, because I want to get my hands on the open source Enso Project.
So, after installing scons I went to the console and tried to compile it using scons, but I got this error:
C:\oreyes\apps\enso\enso-read-only\src\platform\win32\Include\WinSdk.h(64) : fatal error C1083: Cannot open include file: 'Windows.h': No such file or directory
scons: *** [src\platform\win32\InputManager\AsyncEventProcessorRegistry.obj] Error 2
scons: building terminated because of errors.
After checking these links:
VS ans PSDK
Include tiffi.h
Wndows.h
I've managed to configure my installation like this:
And even run this script
And I managed to compile the file below in the IDE.
// Test.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}
But I still get that exception in the console. Does anyone have scons experience?
EDIT
Actually (and I forgot to tell you this) I started the command prompt with the link "Visual Studio 2005 Command Prompt".
I assume this will include the paths in environment variables. Well after printing them I find that it didn't:
echo %INCLUDE%
echo %LIB%
echo %PATH%
And they were not present, so I created this .bat file:
set PATH=%PATH%;"C:\Program Files\Microsoft Platform SDK\Bin"
set INCLUDE=%INCLUDE%;"C:\ Program Files\Microsoft Platform SDK\Include"
set LIB=%LIB%;"C:\ Program Files\Microsoft Platform SDK\Lib"
Still, scons seeems not to take the vars... :(
Using the above recommendations will not work with scons: scons does not import the user environment (PATH and other variables). The fundamental problem is that scons does not handle recent versions of SDKs/VS .
I am an occasional contributor to scons, and am working on this feature ATM. Hopefully, it will be included soon in scons, but the feature is much harder to implement reliably than I first expected, partly because every sdk/compiler combination is different (and sometimes even MS does not get it right, some of their .bat files are broken), so I can't give you a date. I hope it will be included in 1.2 (to be released in approximatively one month).
You need to set the include file path (and possibly other things). At the command line this is typically done using a batch file that Visual Studio installs called vsvars32.bat (or vcvars32.bat for compatibility with VC6).
I'm not familiar with scons so I don't know the best way to get these settings configured for that tool, but for standard makefiles there's usually a line in the makefile which sets a macro variable with the include directory path and that macro is used as part of a command line parameter in the command that invokes the compiler.
Another possibility might be to have the scons process invoke vsvars32.bat or run the scons script from a command line that has been configured with the batch file.
In short you need to get the things that vsvars32.bat configures into the scons configuration somehow.
There will be a batch file similar to this one (for MSVC 2005) that sets up the environment variables:
c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat
Step 1: Find a similar file in the Express installation folders
Step 2: Create a shortcut on the desktop with these target details and a suitably modified path:
cmd.exe /K "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"
Step 3: Open the DOS prompt via this shortcut
The command line build should now work from within this console window.
You show us how you configured Visual Studio for compilations within Visual Studio but you didn't show us what command line environment you tried. Sorry I haven't tried Express versions so I don't know if they create additional Start menu shortcuts like Pro and above do. If you open a suitable command prompt with its environment variables already set then you can compile on the command line. Otherwise you have to set variables yourself or execute a batch script to set them, each time you open a command prompt.
It'll be nice when scons does this automatically. For now, I use this (run from an SDK command prompt, not sure if there is a difference if run after vsvars32.bat):
import os
env = Environment(ENV={'PATH': os.environ['PATH']})
env['ENV']['TMP'] = os.environ['TMP']
env.AppendUnique(CPPPATH=os.environ['INCLUDE'].split(';'))
env.AppendUnique(LIBPATH=os.environ['LIB'].split(';'))
This works for me while compiling wxwidgets with Visual C++ 2005 Express using the command line prompt:
REM Fix Error error C1083 'windows.h'
(Use /useenv option when compiling.)
set PDSKWIN=C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2
(Change to the right one.)
set INCLUDE=%PDSKWIN%\Include;%INCLUDE%
set LIB=%PDSKWIN%\Lib;%LIB%
Then I use this line when compiling. I believe just add /useenv to your lines and everything should work fine:
vcbuild /useenv /nohtmllog /nologo name.proj (or any file to compile)
Related
I wrote a python script which runs some Modelica scripts file for Gitlab pipeline continuous integration. I could get the python script to work from command line without any issues, however, whenever I trigger the pipeline in Gitlab, I got errors below, I am curious if anyone encountered similar issues and could provide a solution possibly?
No compiler selected. Please select a version of Visual C++ or GCC. For instructions on how to install a supported compiler, please visit www.dymola.com/compiler.
I tried to use SetDymolaCompiler method, but it still gives me the same error.
(BTW, the documentation in the python interface was incorrect. In the documentation, string lists (see marco's answer and my correction) were used to set compiler location, however, I figured that it should be a map actually).
Here's the code I was running:
dymola_obj = None
try:
dym_obj = DymolaInterface(dymola_exe)
dym_obj.cd(mc_work_dir)
dym_obj.SetDymolaCompiler("vs", {"CCompiler":"MSVC","MSVCDir":"C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc"})
success = dym_obj.ExecuteCommand("some command")
except DymolaException as ex:
success = False
finally:
if dym_obj is not None:
dym_obj.close()
dym_obj = None
return success
OS: Win 10 Pro (on a VM)
Dymola: 2018 FD01
Correction:
Python interface documentation is still incorrect, in order to change compiler settings one should use [] instead of { }.
Python interface documentation:
SetDymolaCompiler("vs", {"CCompiler=MSVC","MSVCDir=C:/Program Files (x86)/Microsoft Visual Studio 10.0/Vc"});
Should be changed to:
SetDymolaCompiler("vs", ["CCompiler=MSVC","MSVCDir=C:/Program Files (x86)/Microsoft Visual Studio 10.0/Vc"]);
I didn't try with gitlab, but I found an error when running your code on my machine with Dymola 2018 FD01 and python 2.7.
In fact SetDymolaCompiler really does require a list of strings. You have to replace the line
dym_obj.SetDymolaCompiler("vs", {"CCompiler":"MSVC","MSVCDir":"C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc"});
with
dym_obj.SetDymolaCompiler('vs', ['CCompiler=MSVC', 'MSVCDir="C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc'])
Some tips when working with the python interface:
activate the Dymola window during development with
DymolaInterface(showwindow=True)
set breakpoints and check after every command what Dymola writes to the command window. In your case it got obvious that SetDymolaCompiler was not executed due to syntax errors and the compiler was not set
And finally, your minimal example does not work, as python code lines must not end with ;
I have downloaded the boost library and want to include it in visual c++, but after copying in a piece of example code from the boost website, I get the error
"LNK1104 cannot open file 'libboost_regex-vc100-mt-gd-1_54'"
The file certainly exists. I'm guessing it was created when I ran the bootstrap command in the command prompt, which I followed from the guide https://www.youtube.com/watch?v=6trC5zVXzG0
The example file I use is as follows:
#include <boost/regex.hpp>
#include <iostream>
#include <string>
using namespace std;
int main()
{
string line;
boost::regex pat("^Subject: (Re: |Aw: )*(.*)");
while (cin)
{
getline(cin, line);
boost::smatch matches;
if (boost::regex_match(line, matches, pat))
cout << matches[2] << endl;
}
return 0;
}
I'm sorry but I know this kind of question has appeared several times on stack overflow, but I have tried most of the solutions I've seen and the error still exists.
Inside the solution explorer in visual c++ 2015, I write click on my proect and then click on properties, then under the VC++ directories tab, I've added the directory "C:\Program Files\Boost" into include directories, and the directory "C:\Program Files\Boost\stage\lib" into library directories. But the problem still exists. Similar questions on stack have asked to add the directory "C:\Program Files\Boost\stage\lib" to the Additional Include Directories under the general tab under the C/C++ tab, and to the Additional Include Directories under the General tab inside the Linker tab. But all these changes made no difference to the error. Another solution on stack said to add the directory "C:\Program Files\Boost\stage\lib" to the Additional dependencies under the input tab under the Linker tab, but when I did this the error changed to:
"LNK1104 cannot open file 'C:\Program Files\Boost\stage\lib.ob'"
I'm not sure if this is an improvement to the error or not
So after trying all these solutions which seemed to work for other people, I keep getting the same error. So does anyone know what could be the cause of the error.
You are getting a LNK error, which means it's likely that something is missing from your Linker properties. Make sure you've added both the boost folder and the boost\stage\lib folder to the Project Properties > configuration > Linker > "Additional Library Directories".
Also note that if you're using Visual Studio 2015, you should probably have generated the boost binaries using msvc-14.0, not msvc-10.0. Otherwise, your Platform Toolset property should be set to v100 (the default will be v140). You change this setting from Project Properties > configuration > General > "Platform Toolset", but you would need to have that version of visual studio installed.
If Aciel's answer haven't solve your problem(because I saw you haven't accept that answer yet), I believe it is because you compile your boost lib to 32-bit, and you use them in a 64-bit program.
If it's so, please try
bjam --toolset=msvc-14.0 --build-type=complete address-model=64
to rebuild your boost lib to 64-bit
Is there a way to launch Microsoft Visual Studio Code from the command line in windows? I can't even seem to find the directory for code on my computer. It didn't even ask me where to download it.
Navigate to the directory that you want to open and type code . to launch VS Code.
As many folks already suggested ways to open code from command prompt using code . command. This will only open Visual Studio Code Stable build. But If you have downloaded Visual Studio Code Insider build/version (Which has all latest build/features but unstable version) then you need to follow below instructions in windows :
Go to Control Panel\System and Security\System. Click on Advanced System Settings
Click on Environment Variables
Under System Variables tab, Click on Edit for Path Variable
Add a new path C:\Users\tsabu\AppData\Local\Programs\Microsoft VS Code Insiders\bin
(or)
C:\Program Files\Microsoft VS Code Insiders\bin based on location at which you have installed vscode insider in your machine.
Open a new command prompt and type code-insiders . to open vscode-insider
build/version
Short answer:
code your_path your_filename
Long answer:
Here your_path can simply be . if you want to use the current directory as your working path. Or .. for 1 level up, etc.
code is the name of the executable of Visual Studio Code (code.exe). If it doesn't launch, perhaps your VSC path hasn't been added to the path environment variable. Run this command to add it:
set PATH=";C:\Program Files\Microsoft VS Code\bin"
Of course you'll need to specify a different path if your VSC is installed somewhere else.
How can you find out the installation path? (click for screenshot) Go to "Start" menu, type in "Visual Studio Code", right click on the found program, "Properties", check "Target". Now you'll see!
It may come already added to your path when installed. Try using code <filename> in your command line. If it's not you can add the command line script's directory to your path. The command line script's directory is downloaded by default in the following location
C:\Users\<username>\AppData\Local\Code\bin
Point your command prompt to the specific folder that has the file that you want to open. Let's say you want to open the file titled main.scss. Simply run this command:
start code main.scss
If Visual Studio Code is already open, you can simply do:
code main.scss
The VS environment variable is set beforehand with vcvars32.bat, and VS is the only compiler that I use; the OS is win 7.
The error happens with cmake-gui; specifying the compiler with path results in error 'compiler failed to make simple test'; alternatively, cmake -i from command line succeeds initially with presenting an 'options' menu which then fails to allocate a 'cmakelists.txt' file (which is somewhere deeper in the cmake folder).
Where am I going wrong?
(I continued with building the solution files from VS 12, but there's other issues.)
The answer to your question from cmake mailing list
Run cmake-gui FROM the target environment, just like you run cmake...
i.e. : type "cmake-gui" in the cmd prompt that has your stuff set up
in it. Don't just launch it from a short-cut unless you're using the
"Visual Studio *" generators. Those do not need any special
environment. Many of the makefile ones do.
I'm setting up our build server. I've installed Jenkins on a Windows 7 machine and am running into problems when building the 64 bit version of our solution.
We're using Visual Studio 2012 Express for Windows Desktop. Jenkins uses the MSBuild plugin and is targeting the 64 bit MSbuild exe at
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
However, when it runs msbuild an evironment variable is not being parsed properly. VCTargetsPath.
If I leave everything as-is then the output of MSBuild is this
error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I played around a bit with the VCTargetsPath variables in the registry, Windwos Environment Variables and as Jenkins Eviornment Variables too. I noticed this behavior.
If I set VCTargetsPath to be "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110" then the output of msbuild is the same as above. However, if I set it to "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0" then the output changes to this.
error MSB4019: The imported project "C:\progra~2\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The tile Microsoft.Cpp.Default.props is found in "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110" I checked the limits on environment variable length and it's supposed to be 2048 characters. Am I missing something obvious here? I've found some info that basically says I am going to have to reinstall everything in a specific order, which is quite annoying (but also very Microsofty).
I fixed this by adding
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"
or the more elegant
/p:VisualStudioVersion=12.0
into
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments
Your first round of fix-it attempts for a build server.
Install the appropriate SDK on the build machine.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
If that doesn't work, report back.
EDIT:
/p:VisualStudioVersion=11.0
Add that to your command line...as a parameter for msbuild.exe
EDIT:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
I have a 64 bit version of msbuild.exe there.
Which isn't what you show.
I'm throwing a guess out, nothing concrete, FYI.
Try passing : /p:PlatformTarget=x86 as one of the arguments to MSBuild.