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.)
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;
There are a couple of 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
Don't check the box offering to check the project into source control if you're using Visual Studio Express. If you're not paying for Visual Studio, you're probably also choosing not to pay for Microsoft's expensive Team "solutions," and VSE doesn't support third-party VCS plugins, such as AnkhSVN for Subversion.
Fill out the Makefile Project Wizard:
Leave the Output (for debugging) field alone, unless you're doing something odd like not naming your executable after the project name, or putting the executable name somewhere other than the top level of the project.
Leave the rest of the fields alone, unless you know what they are and why you want to change them. Just 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. (And if you don't know how but want to, it's probably a good topic for a new SO question!)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 amake.exe
to yourPATH
. 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 even several tools that make this easier, by generating VS project files and
Makefile
s from a single common source. I happen to use Bakefile, but CMake has become more popular in recent years. SCons also does this job, and is probably also more popular than Bakefile; it's certainly updated more often.