I am creating a very large project (a few thousand lines) and so would rather not use Notepad++. An IDE would make it so much easier. I have experience with Microsoft Visual Studio and love it. Is there some easy way to use Cygwin's GCC from within Microsoft Visual Studio?
Alternately, are there any other good Windows IDEs for GCC besides NetBeans and Eclipse? (I hate both of them with a passion.)
There are several ways to go here:
Option 1: Create a Custom Build Tool
Visual Studio 2005 and newer will let you register custom build tools. They tell the IDE how to transform files of one form (e.g. a .cpp file) into another form (e.g. an .obj file).
So far as I know, no one has done this yet for GCC. And, doing it yourself requires writing COM code, which is probably too deep a pool to dive into just for a single project. You'd have to have a compelling reason to take this project on.
You then have to manually adjust each project to tell it to use the custom build tool instead of the default, since you're using a file name extension (.cpp, probably) that Visual C++ already knows about. You'll run into trouble if you try to mix the VC++ and g++ compilers for a single executable built from multiple modules.
On the plus side, if you were looking to start an open source project, this sounds like a good one to me. I expect you'd quickly gather a big user base.
Option 2: Makefile Project
Start Visual Studio and say File > New Project.
In the Visual C++ section, select Makefile Project
Fill out the Makefile Project Wizard:
Build command line: make
Clean commands: make clean
Rebuild command line: make clean all
You can leave the Output (for debugging) field alone if you've named your executable after the project name and it lands where Visual Studio expects to find it.
Leave the rest of the fields alone unless you know what they are and why you want to change them. As an example, you might choose to pass a -D flag on the Preprocessor definitions line to get separate debug and release outputs. If you know you want this, you know how to set it up, so I'm not going to make this long answer even longer in order to explain it.
You'll be asked the same set of questions for the Release build. If you want to bother with separate debug and release builds, you'd make any changes here.
Having done all this, you still have to create the Makefile, and add a make.exe to your PATH. As with the debug vs. release question, going into that level of detail would push this answer off topic.
As ugly as this looks, it's still easier than creating custom build tools. Plus, you say you need to port to Unix eventually, so you're going to need that Makefile anyway.
Option 3: Cross-Platform Development
You say you want to port this program to Unix at some point, but that doesn't mean you must use GCC on Windows now. It is quite possible to write your program so that it builds under Visual C++ on Windows and GCC/Makefiles on *ix systems.
There are several tools that make this easier. One very popular option is CMake, which is available as an installation time option in newer versions of Visual Studio. There are many alternatives such as SCons and Bakefile.
Clang
You can use the Clang compiler with Visual Studio to target Android, iOS, and Windows.
If you are targeting Android, you can use the Clang/LLVM compiler that ships with the Android NDK and toolchain to build your project. Likewise, Visual Studio can use Clang running on a Mac to build projects targeting iOS. Support for Android and iOS is included in the “Mobile Development with C++” workload. For more information about targeting Android or iOS check out our posts tagged with the keywords “Android” and “iOS”.
If you are targeting Windows, you have a few options:
Use Clang/LLVM; “Clang for Windows” includes instructions to install Clang/LLVM as a platform toolset in Visual Studio.
Use Clang to target Windows with Clang/C2 (Clang frontend with Microsoft Code Generation).
GCC
If your project targets Linux or Android, you can consider using GCC. Visual Studio’s C++ Android development natively supports building your projects with the GCC that ships with the Android NDK, just like it does for Clang. You can also target Linux – either remotely or locally with the Windows Subsystem for Linux – with GCC.
Check out our post on Visual C++ for Linux Development for much more info about how to use Visual Studio to target Linux with GCC. If you are specifically interested in targeting WSL locally, check out Targeting WSL from Visual Studio.
Source: https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/
I'm from the future.
I keep (poking at) a C/C++ toolchain using Visual Code on Win/Lin/Mac and MinGW installed from Choclatey.
(This was done for my sanity - install GDB and GCC however you want)
I've run it with GCC and GDB with IntelliSense using MS's own weird JSON makefiles.
Someday, someone (you?) will write a Gradle or Python script to generate these; for now the examples online in the docs seem to work.
It seems to require three types of JSON thing;
a single IntelliSense configuration for the whole workspace
a Debugging Configuration entry for each binary you want to debug
these can invoke the build tasks
a Build Task per-artifact
I don't think that there's a "require" or "dependency" thingie-mah-bob; sorry
Related
before I explain my current problem with Visual Studio in combination with CMake, I try to explain what I want to accomplish as there might be a better solution.
At our company we have a huge code base mainly written in C for QNX. For development we are using the standard IDE QNX momentics. As this is based on a quite old eclipse version ... the whole IDE sucks.
I'm currently evaluating to use Visual Studio as a replacement. With a really simple HelloWorld-programm I was able to build and debug the project from within VS using CMake and a CMakeSettings.json.
As our code base is basically organized in a tree-like structure, I've created a typical hierarchy of CMakeLists.txt which allows me to build single/multiple projects.
As QNX delivers its own compiler I've created a toolchain file, this is running fine so far, the required toolchain is invoked once a build is triggered via cmake.
Now for the part that I'm struggling with:
How to use this CMake setup in order to develop/debug code from VS?
I had two ideas in mind which don't really work or I'm doing something wrong.
Use the CMake generator for VS 2019 and generate a complete solution. Problem: The toolchain file is not "used" as all projects will be setup with the internal VS compilers. Is there any way to get this working? I thought calling cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE=$FILE would do the job. Additionally: how would I incorporate the debugger configuration? With this solution the CMakeSettings.json seems to be ignored as VS solutions are used.
Use File->Open->CMake to open the root project. Shouldn't this show all "contained" projects which also include a CMakeLists.txt as projects? I can only see the folder tree in the Solution Explorer. Build a single project from the solution explorer is also not possible ... there is simply no option.
Anyone with experience on this topic?
Minor comment please limit questions to 1 question in the future. Multiple questions clutters questions and makes search results worse.
============================================================
I'll answer question #1 this part of question number 1.
"Use the CMake generator for VS 2019 and generate a complete solution. Problem: The toolchain file is not "used" as all projects will be setup with the internal VS compilers. Is there any way to get this working? I thought calling cmake -G "Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE=$FILE would do the job."
Instead of using Visual Studio as your generator try using "Ninja" instead. Ninja will work if your toolchain code is correct. Toolchains and visual studio are complicated to say the least. If you wanna go down that rabbit hole I can help but that's a separate question
Basically try switching to Ninja instead of Visual Studio as your generator for CMakeSettings.json. Ninja is very easy to write toolchains for.
======================================================================
"Additionally: how would I incorporate the debugger configuration?"
The MSDN articles are actually quite good. I figured it out this week. In my opinion the debugger configurations are more powerful with the CMake approach than vanilla visual studio.
Configure CMake debugging sessions
https://learn.microsoft.com/en-us/cpp/build/configure-cmake-debugging-sessions?view=msvc-160
"Tutorial: Debug a CMake project on a remote Windows machine"
https://learn.microsoft.com/en-us/cpp/build/cmake-remote-debugging?view=msvc-160
Trust me once it clicks you'll love it.
I am working on SFML and I am curious about the option that I can compile it myself. I found it in tutorials, but from the first line I became confused:
CMake is an open-source meta build system. Instead of building SFML, it builds what builds SFML: Visual Studio solutions ...
There is a build option in visual studio too, is there any difference between that build and CMake build?
What does it mean that it builds what builds SFML? It means library files?
Visual studio solutions? What does it mean? As far as i know, when i open a new project it is within a solution and i can add new projects to this solution (I am confused about why there must be more than one project in a solution too!).
What does it mean that CMake builds a solution? And what is it for?
There is sourcecode. People want to compile it. It is difficult and annoying to type the compile commands into a terminal.
People invent build systems, to make 1.) more easy. For example make files or what Visual Studio integrates and stores in its files, called solution.
There are projects, that are cross-platform. They could provide make files, solution files, files for Xcode, Eclipse and so on. This becomes difficult and annoying.
People invent systems, that creates build system to ease 3.). From a common set of files, several different build systems can be steered.
In your actual case: CMake creates the solution file, you can open the solution file and built SFML with that.
CMake is a wonderful tool for cross-platform development without the hassle of maintaining separate build utilities. On Windows, CMake can create a Visual Studio solution file based on its CMakeLists.txt file. On Linux, generally CMake outputs a makefile. CMake is compatible with many build tools, I recommend reading more of there documentation on their website to gain more information.
Edit: Just to be more clear. CMake literally builds what builds SFML since it creates the Visual Studio solution used to build SFML.
A build in VS for a solution is building the library itself. A CMake build generates the VS solution with which you would use to build the library.
See 1.
A VS solution is the full buildable setup containing 1 or more projects. Solutions can contain multiple projects since VS has a limitation on only 1 output per project. If you want multiple outputs (e.g. 4 dlls) each output needs it's own project.
First, going to be honest. I'm a c#/java-language-level dweller. So I have no idea about how to compile native-C projects such as opus.
I've tried doing it myself, and I've tried googling it. I simply need help compiling the opus-codec API (on Windows).
Once I have the library compiled, I'll build a wrapper for it's API.
While my searches have indeed found opus wrappers targeting my current project's language (c#), I can't find an up-to-date one. I don't know if it matters, but I need it for it's VoIP capabilities.
Sorry for my stupidity in the matter.
[UPDATE]
After compiling with Visual Studio 2010: Ultimate, I have a .lib library file. I need a .dll. I don't know what I'm doing. Help?
In a C project there is going to be some way to drive a build of all the object files, libraries, etc. Basically the same thing as maven build in Java, just with different tools. You will have to have the right tools if you don't.
On unix systems it's usually Makefile driven, running command line programs that compile and link the program or library that is being built. In GUI environments like XCode or Visual Studio, there are ways to run the build directly from the UI.
Looking at the source tree, there's a directory with a number of Visual Studio 2010 projects in it - https://git.xiph.org/?p=opus.git;a=tree;f=win32/VS2010
If you're using Visual Studio, loading that up and trying a build to see if it still works is where I'd start. Or perhaps have a look at Any way to do Visual Studio "project only" build from command line? or other questions that reference msbuild.
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
I have a Makefile that I use to build my application in both Windows and Linux. All complex project- and platform-related stuff are already dealt in this Makefile.
Today, I use a common editor to code and call GNU make from command line. Now I am considering to move to Microsoft Visual Studio 2010. I already use MSVS2010 when debuging using a not-configured Intel Visual Fortran Empty Project with my files.
I don't want to duplicate my work configuring a new Visual Studio project and I want to use the Makefile instead.
Is there a way to do it with MSVS2010? Or, is there any other better way to keep the configuration at one place "usable" from Windows and Linux?
In the somewhat distant past I used VC++2005 in just this way. The trick is to create an external project (or command-line project or something like that—I forget the terminology now). The command-line you give to this project is make -j4 target (ymmv). Naturally the makefile needs to use cl as the compiler, link as the linker &c.
Now everthing is hooked up, and you can press the f7 key in VC++ to build your project, and f4 takes you through the errors. [I used cygwin make, and it all worked rather well.]