I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
Related
I am trying to statically build Qt using Visual Studio 2013
To do so, I'm following the instructions provided by the official website
1) ActivePerl 5.20 is downloaded, installed and added to the PATH.
2) The archive for qt-everywhere-enterprise-src-5.3.1 is downloaded and unzipped in C:\Qt\Entreprise_2
3) I open msvc 2013 command prompt, and change directory to: C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1
4) From here, I add 2 new elements to the path:
SET PATH=C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1\qtbase\bin;C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1\gnuwin32\bin;%PATH%
5) I define the QMAKESPEC in order to use msvc: SET QMAKESPEC=win32-msvc2013.
6) finally, I launch the compilation:
configure -commercial -nomake tests -nomake examples -debug -static
If I skip part 5), I instead receive the
I receive the answer:
"QMAKESPEC environment variable is set to "win32-msvc2013" which is not a supported platform"
If I skip step 6, I obtain instead:
"Unable to detect the platform from environment. Use -platform commandlineargument or set the QMAKESPEC environment variable and run configure again"
However, according to Qt support center:
1) "win32-msvc2013" is the correct QMAKESPEC to use with Visual Studio
2) If we use Visual Studio Command prompt (as I did) instead of the normal one, setting QMAKESPEC is optionnal anywey, as visual studio is supposed to set the correct parameters at the beginning
So, does anyone have any idea about how I could resolve these errors?
Incidentally does anyone knows what defines a Qmakespec as corresponding to a "supported platform"?
Had the same problem, first go look in the mkspecs folder (from the archive) and make sure your platform is there, might not be supported or look here:
http://doc.qt.io/QtSupportedPlatforms/index.html
If your platform is supported and you have it in your extracted mkspecs folder, then no clue what your problem is?!?
Apparently, a good part of the files inside the mkspec folder either failed to copy when I extracted the archive, or were destroyed afterward. Most likely the latter, as it would appears that every time I try to launch a compilation some source file are erased.
The solution I found is to recreate the source file from the archive before every compilation.
I want to be able to program LUA in Visual Studio 2013 Ultimate. I have BabeLua to try to do this. In the program there is a tab called settings. Within that tab there are 5 textboxes that I do not understand
LUA Scripts Folder -
Folder where the files are stored? (Documents/Visual Studio 2013/ Projects)?
Lua exe Path
Working Path
Command line
Setting Name
Can someone give me an explanation to all of these Fields?
This prompt seems to be slightly different than the one I am seeing with the latest update of babelua, but regardless:
Lua scripts folder: This should be the explicit path to some file folder where your script is located.
Lua exe path: explicitly provide the path to your exe (which you can download from here.
Note: be sure to download the windows 32 Bit version, even if your machine happens to be 64 bit. There appears to be some sort of bug
that prevents Babelua from running in debug mode with the 64 bit
version.
Working path: I just provide the same path to the folder containing the lua exe.
Command line: This is where you provide the name of the script(s) you want to run. If you wrote a file in your project called "script.lua" you would provide the name of that file, with the extension, in this area.
Lua project name: This is different than the "setting name" prompt you have, but its rather self-explanatory.
Example:
Lua scripts folder: C:\Users\kevin1michael\Documents\LuaScripts
Lua exe path: C:\Users\kevin1michael\Documents\Lua\32BitLua\lua5.1.exe
Working path: C:\Users\kevin1michael\Documents\Lua\32BitLua
Command line: script1.lua
Lua project name: Project1
I'm trying to get tcl/tk working in Windows 7 64bit. I've followed the readme on the main tcl's website and what I've done so far is run the make file found in the tcl8.6.1 .zip file you can get off of the tcl website. I was able to compile it with the terminal window in Visual Studio C++ 2010 professional. The make file creates a folder inside your downloaded and extracted tcl folder that you can then run and compile tcl scripts from that specific location but from nowhere else. I want to be able to compile and run tcl scripts from any directory since I'll be doing a bit of tcl/tk programming in the near future.
Stuff I've tried:
1. Copying the tclsh86t.dll file + tclsh86t.exe file to system32
2. Editing the TCL_LIBRARY environment variable but it doesn't exist :/
Any ideas?
I figured it out. In Windows:
Open a file explorer
Right click on "computer" select "properties"
Select "Advanced System Settings"
Select "Environment Variables" in the "Advanced" tab.
Edit the "Path" variable to have the location of "tclsh86t.exe" available when compiling the latest version of tcl.
When you re-open your command line, you should be able to use tclsh86t.exe from anywhere. In my case, tcl was complaining that it couldn't find a usable init.tcl file. So, I went and grabbed one from the tcl distribution and put it where it was looking and then it was fine. You can alternatively edit your TCL_Library environment variable to point to wherever it is on your PC.
I have 2 questions regarding NGINX:
Is there any one who had already compile NGINX with Visual Studio? I want create a VS9 Project for compiling NGINX.
It's my veritable need, is there any way to compile NGINX as Lib or DLL?
I just finished building a Visual Studio 2010 project for nginx. The process wasn't entirely straight-forward, so I will attempt to detail everything I've learned. This is a several-hour to several day process, depending on your experience.
Step 1: You must first follow the Guide for building nginx on windows. This not only builds nginx, but also creates .c and .h files that you will use when creating your Visual Studio project. It won't work without these files. (For more information, see here.)
If you are less experienced with Unix like me, the guide above leaves some unanswered questions. So I'll first flesh out that guide with tips of my own, and then later, tell you more about creating a project for Visual Studio.
Part I: Compiling nginx for windows using MSYS
First, follow all the steps given above. Install MSYS, Strawberry Perl, Mercurial, and download the PCRE, zlib, and OpenSSL libraries. Then follow these steps:
1) Open a command prompt As Administrator. Then run your Visual Studio vc\vcvarsall.bat file to set
your environment variables to use VC as the compiler. Your paths will be different, but the command I used was:
"C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
I found that even though the Strawberry Perl added 3 paths (which you can verify by examining your PATH variable), it still was using the wrong Perl.
2) Launch MSys by running msys.bat. For me, MSys was installed inside of the MinGW directory, so my path was:
C:\MinGW\msys\1.0\msys.bat
If successful, you should see something like this in green:
JensenV#AVWMA047LB ~
(except with your username#networkaddress instead) in a window called something like MINGW32:~
You might be wondering where your 'home folder is. It's under msys\1.0\home. So on my system, it's here:
C:\MinGW\msys\1.0\home\JensenV
If you do "ls" or "dir" this is the directory you're in initially.
3) Assuming you installed Mercurial as instructed above, you should now be able to check out ngynx source:
hg clone http://hg.nginx.org/nginx
This will go into the directory mentioned above.
4) You need to make sure the version of perl being used is strawberry perl, NOT the version that comes with msys. Type:
which perl
If you get something like "/bin/perl.exe" that's the wrong perl and you need to fixing your paths. You can either mess with this (as I did, unsuccessfully) OR you can just disable the version of perl that comes with msys. I just renamed
perl.exe to perl_UNUSED.exe in my msys install:
C:\MinGW\msys\1.0\bin
Whatever you do, make sure "which perl" shows the path to Strawberry Perl before proceeding.
5) Also renamed "link.exe" in my msys\1.0\bin directory:
C:\MinGW\msys\1.0\bin
so that it's unused. (i.e. rename it to "link_UNUSED.exe")
I believe this is because, in Step 1 above, your "vcvarsall.bat" set everything to use Microsoft C's compiler/linker, but then in Step 2, the linker was changed to use the Msys one instead. You need to use the Microsoft one.
To verify renaming as "link_UNUSED.exe" was successful, type:
which link
and ensure it points to your Visual Studio 10 link, not the link.exe that came with msys.
6) First "cd nginx" then create an objs/lib folder tree inside of the nginx folder. Untar/unzip pcre, zlib, and openssl in here as mentioned in the guide.
7) While your current directory is still nginx, run nginx's autoconfigure script, but first modify the command below to change the paths for
sopenssl, pcre, and zlib to be correct for what you installed in objs/lib (your version numbers may be different). The command I used was:
auto/configure --with-cc=cl --builddir=objs --prefix= \
--conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \
--http-log-path=logs/access.log --error-log-path=logs/error.log \
--sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 \
--with-pcre=objs/lib/pcre-8.33 \
--with-zlib=objs/lib/zlib-1.2.8 \
--with-openssl=objs/lib/openssl-1.0.1f \
--with-select_module --with-http_ssl_module --with-ipv6
If you want to change any configuration options, NOW IS THE TIME. These options affect the generated .c and .h files that you will use later in creating your Visual Studio project, and trust me, you don't want to have to redo that later when you realize you need different options.
7) Make it.
nmake -f objs/Makefile
If successful, your freshly compiled nginx.exe should be inside your home\YourUsername\nginx\objs folder. i.e. something like:
C:\MinGW\msys\1.0\home\JensenV\nginx\objs
In addition, these files will now be in the same folder as nginx.exe:
ngx_auto_config.h
ngx_auto_headers.h
ngx_modules.c
ngx_pch.c
You will use these in creating your Visual Studio project.
8) Have a beer.
**
Part II: Creating the Visual Studio nginx Project
**
Create an empty Visual Studio project for Command Line application. Save the project inside your nginx folder (root level). Note that before this step you can move your nginx folder outside of msys to wherever you want to keep it.
1) Go to Properties -> VC++ Directories and add these Include Directories:
$(MSBuildProjectDirectory)\src\core
$(MSBuildProjectDirectory)\src\event
$(MSBuildProjectDirectory)\src\event\modules
$(MSBuildProjectDirectory)\src\http
$(MSBuildProjectDirectory)\src\http\modules
$(MSBuildProjectDirectory)\src\http\modules\perl
$(MSBuildProjectDirectory)\src\mail
$(MSBuildProjectDirectory)\src\misc
$(MSBuildProjectDirectory)\src\mysql
$(MSBuildProjectDirectory)\src\os
$(MSBuildProjectDirectory)\objs
$(MSBuildProjectDirectory)\src\os\win32
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\include
$(MSBuildProjectDirectory)\objs\lib\zlib
$(MSBuildProjectDirectory)\objs\lib\pcre
NOTE: Before this step I went into objs/lib and removed the version numbers from the zlib, pcre, and ssl folders. Either you should do this to, OR you should modify the paths above to match your installed versions. I removed the version numbers so that I can update to newer versions of these libraries in the future without breaking my project.
Click on the "Macros >>" button and verify that the MSBuildProjectDirectory path is a path to your nginx folder.
2) Likewise add these paths to your Library Directories:
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\lib\
$(MSBuildProjectDirectory)\objs\lib\pcre\
$(MSBuildProjectDirectory)\objs\lib\zlib\
Again, modify these paths to include version numbers if your objs/lib folder's contents still have version numbers.
3) Change these Project Properties as follows:
C/C++
General: Set "Treat warnings as errors" to No (WX-)
Preprocessor: Add these Preprocessor Definitions:
WIN32
NGX_WIN32
NGX_MAIL_SSL
NO_SYS_TYPES_H
FD_SETSIZE=1024
Linker:
Input: Add the following to Additional Dependencies:
ws2_32.lib
pcre.lib
ssleay32.lib
libeay32.lib
crypt32.lib
zlib.lib
4) Close your Visual Studio solution. Open up the project file (ends in .vcxproj) with a good text editor, such as Notepad++. (Make a backup copy of it first, in case anything goes wrong.) Also open up nginx\objs\makefile with a text editor.
In the makefile, not too far from the top, you'll see a section that starts something like this:
objs/nginx.exe: objs/src/core/nginx.obj \
objs/src/core/ngx_log.obj \
objs/src/core/ngx_palloc.obj \
objs/src/core/ngx_array.obj \
....
objs/ngx_modules.obj \
objs/nginx.res \
objs/lib/pcre-8.33/pcre.lib \
objs/lib/zlib-1.2.8/zlib.lib
$(LINK) #<<
Likewise, in the Visual Studio file, if you've added any source code (add any files you want prior to this step, so you can see what I'm talking about) you'll see something like this:
Create a new document containing just the .obj files from the makefile. Use Search & Replace in a text editor to modify them to match the format of the Visual Studio project file instead (so ending in .c /> instead of with .obj \, and starting with
Also don't forget to change the forward slashes to backslashes. Don't include the zlib.lib or pcre.lib lines. I forget if you should include nginx.res. (Probably not.)
Once you're sure the format is right, save your Visual Studio project and try opening it. If all the files from the makefile show up in your project, you did it correctly.
5) Remember those special .c and .h files that nginx created when you built the exe? You want to add them to your project now, too. Add these guys:
ngx_modules.c
ngx_pch.c
6) Now you're ready to compile!
I've honestly probably forgotten something along the way, so you might still have some linker or compile errors to fix, but this should give you a good start!
NOTE: If you want to change which options are included in nginx, you'll have to do a new auto/configure in Part I above, a new nmake, and then include additional source code in you Visual Studio project, and use the newly generated ngx_modules.c and ngx_pch.c files in your Visual Studio project.
I have a python build script I'm using to build a number of projects that are configured via CMake on windows. Previously, we used MSVC to build these projects, and everything was fine. I want to try to incorporate ICC into the build now, via these python scripts. I can choose the native compiler directly in the UI if necessary, but I'd rather do everything programmatically.
Problem is, it's failing with either syntax errors, or just not paying attention to the cmake options.
I can set:
"CMAKE_CXX_COMPILER:PATH":"C:/Program Files (x86)/Intel/Composer XE 2013/bin/intel64/icl.exe",
"CMAKE_C_COMPILER:PATH":"C:/Program Files (x86)/Intel/Composer XE 2013/bin/intel64/icl.exe"
And that's part of a cmakeItems array that's then fed into the generation:
generate(x86Generator, cmakeItems, osName, buildTarget)
where the other options are set via command line switches (for x86generator and buildTarget) or by default (ie, osName is detected in the script itself).
Before trying anything, I'm running this from a command line prompt where I've run
iclvars intel64
in the icc bin directory to ensure that all of the icc variables are properly configured, and I can type icl on the command line and confirm that it's in the path.
Running the above means that the C compiler remains the default msvc compiler.
I've also tried running:
set(CMAKE_C_COMPILER_INIT icl)
set(CMAKE_CXX_COMPILER_INIT icl)
but that's giving me a syntax error on the icl portion. I thought that maybe it's a path issue, but doing:
set(CMAKE_C_COMPILER_INIT "C:\Program Files (x86)\Intel\Composer XE 2013\bin\intel64\icl")
set(CMAKE_CXX_COMPILER_INIT "C:\Program Files (x86)\Intel\Composer XE 2013\bin\intel64\icl")
is also giving me a syntax error.
So how can I programmatically set the C/CXX compiler from a python script calling cmake?
On the command line you specify the compiler via the environment variables CC and CXX. I'ld guess you need to properly prepare the envornment of the cmake command and you should not change CMakeLists.txt internals.
E.g.
import subprocess
subprocess.Popen('CC=%s CXX=%s cmake ../path/to/src' %('icc','icpc'))
The answer is:
ICC does not work with CMake on Windows, so don't bother.
http://www.cmake.org/Bug/view.php?id=6929
Much better to run it with some form of visual studio compiler and then mess about with icprojconverter:
http://software.intel.com/en-us/articles/ICProjConvert100