How do you port C++ programs with makefile made from GNU C++ in Linux to Visual C++?
One thing I can suggest is to use CMake. If you implement your build system with CMake to auto-generate the makefiles for GCC on Linux, it takes only minor modifications to auto-generate projects and solutions for VC++.
Of course, this means learning a whole new build tool, so it may not be for you. It's only a suggestion.
I don't know about an easy way to simply convert from one to another, but..
Assuming you use only ANSI C/C++ features, usually you don't need to convert the makefile, just look which .c/.cpp files are in it and add them to the VS project; you'll also have to check about compiler options and defined macros, to put them inside the VS project. I've done this to compile libs like expat, freetype, agg and others, without problems.
Porting the build system: You could use a Windows port of GNU make, and change the makefile to invoke the Visual C++ command line tools (cl.exe, link.exe, lib.exe, etc.) when building on Windows and the GNU compiler tools when building on Linux. The difficulty of this approach depends on the complexity of the makefiles.
Porting the code: This depends on what APIs and libraries you are using, and what compiler warnings/errors/quirks you will encounter. For a more specific answer, ask a more specific question.
CMake was mentioned. I have used CMake and successfully compiled the resulting Visual Studio project. I found the CMake documentation very unhelpful -- I had to ask an existing user -- and the official manual (which costs money) was out of print at the time. Further, the Visual Studio project it produced was very rigidly formatted according the template preferred by whoever wrote the converter. I was unable to figure out how to customize project options or group source files.
I regularly cross-compile on Visual Studio and G++. For the most part, you just need to add all of the source files and header files into a Visual Studio project ('Add Existing Files', and add your entire source tree) and then compile it. Usually you'll get errors, so you start fixing bugs from there. If you used platform-specific libraries, you may be stuck porting to an alternative or removing features.
One further word of caution: Visual Studio and G++ have different compiler quirks. For the most part, they both conform excellently to the C++ standard, but slightly off-standard code which works in one may not work in the other. I have found this to be particularly true when dealing with templates, with Visual Studio being bizarrely permissive of syntax errors in many cases.
CMake has the nicety of generating visual studio project.
If you do not need that, I suggest Meson build system. Much nicer, similar proposal. Requires python3 and ninja, but noone is perfect. :)
Related
I code in C/C++ and use a (GNU) Makefile to compile the code. I can do the same with CMake and get a Makefile. However, what is the difference between using a Makefile and CMake to compile the code?
Make (or rather a Makefile) is a buildsystem - it drives the compiler and other build tools to build your code.
CMake is a generator of buildsystems. It can produce Makefiles, it can produce Ninja build files, it can produce KDEvelop or Xcode projects, it can produce Visual Studio solutions. From the same starting point, the same CMakeLists.txt file. So if you have a platform-independent project, CMake is a way to make it buildsystem-independent as well.
If you have Windows developers used to Visual Studio and Unix developers who swear by GNU Make, CMake is (one of) the way(s) to go.
I would always recommend using CMake (or another buildsystem generator, but CMake is my personal preference) if you intend your project to be multi-platform or widely usable. CMake itself also provides some nice features like dependency detection, library interface management, or integration with CTest, CDash and CPack.
Using a buildsystem generator makes your project more future-proof. Even if you're GNU-Make-only now, what if you later decide to expand to other platforms (be it Windows or something embedded), or just want to use an IDE?
The statement about CMake being a "build generator" is a common misconception.
It's not technically wrong; it just describes HOW it works, but not WHAT it does.
In the context of the question, they do the same thing: take a bunch of C/C++ files and turn them into a binary.
So, what is the real difference?
CMake is much more high-level. It's tailored to compile C++, for which you write much less build code, but can be also used for general purpose build. make has some built-in C/C++ rules as well, but they are useless at best.
CMake does a two-step build: it generates a low-level build script in ninja or make or many other generators, and then you run it. All the shell script pieces that are normally piled into Makefile are only executed at the generation stage. Thus, CMake build can be orders of magnitude faster.
The grammar of CMake is much easier to support for external tools than make's.
Once make builds an artifact, it forgets how it was built. What sources it was built from, what compiler flags? CMake tracks it, make leaves it up to you. If one of library sources was removed since the previous version of Makefile, make won't rebuild it.
Modern CMake (starting with version 3.something) works in terms of dependencies between "targets". A target is still a single output file, but it can have transitive ("public"/"interface" in CMake terms) dependencies.
These transitive dependencies can be exposed to or hidden from the dependent packages. CMake will manage directories for you. With make, you're stuck on a file-by-file and manage-directories-by-hand level.
You could code up something in make using intermediate files to cover the last two gaps, but you're on your own. make does contain a Turing complete language (even two, sometimes three counting Guile); the first two are horrible and the Guile is practically never used.
To be honest, this is what CMake and make have in common -- their languages are pretty horrible. Here's what comes to mind:
They have no user-defined types;
CMake has three data types: string, list, and a target with properties. make has one: string;
you normally pass arguments to functions by setting global variables.
This is partially dealt with in modern CMake - you can set a target's properties: set_property(TARGET helloworld APPEND PROPERTY INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}");
referring to an undefined variable is silently ignored by default;
As mentioned in the other answers CMake can generate other project files. It refers to these projects as generators.
This lets users write/describe their build using a domain specific language, and use the generator to compile the project. It often results in simpler/better code than writing to these project files directly.
A big advantage is users can use the tool that they are the most comfortable with (Makefiles, Visual Studio, XCode, Ninja, etc). This is nice but arguable introduces complexity. Why not just use Ninja?
The answer is history. (As is the norm in C/C++)
Build systems like Visual Studio have tools that will only accept those project files.
For example Microsoft has a feature called "Static Driver Verifier". A tool to analyze the code of kernel mode windows drivers. However, this tool only works on Visual Studio projects since it works alongside msbuild.
msbuild /t:sdv /p:Inputs="Parameters" ProjectFile /p:Configuration=configuration /p:Platform=platform
If your build system can't generate Visual Studio project files, then you can't use the tool. This can be a very big deal for some projects/companies.
I want to know a programming language that doesn't require a runtime/dependency to be installed on the target system. My primary target is Windows XP and above.
I tried Autohotkey but it dosent have many advance functions.
Firstly, please confirm that does 'C++' requires to install a runtime/dependency on the target system is is Win XP or later. Secondly, please suggest me an alternative to C++ that doesnt require a dependency to be installed.
UPDATE: I will be using CodeBlocks! Does the C++ code compiled with that requires a dependency?
UPDATE: Sorry for the misconception, by CodeBlocks I mean the default compiler of CodeBlocks (ie: GNU GCC Compiler or MinGW).
Everything usually depends on the project, not the language. For example, programs compiled in Visual Studio's C++ uses some runtime libraries to work properly. However, you can configure the project in such way, that these libraries are included in the executable file, thus not needing additional dependencies. Delphi works similarly.
Here's the setting for Visual Studio Project:
If you choose option with "DLL", your program will require runtime DLLs. Otherwise it will be standalone, the runtimes will be incorporated into your binary file.
Edit: In response to question edit
I'll repeat myself: it depends on project, not the compiler or IDE.
If you want to create a program that does not require anything else in order to run, except for base operating system (no .NET, no Java, no Perl, no runtime libraries, etc), then your best bet is to use C or C++ and compile your program as single statically compiled executable.
It is rather difficult to achieve in practice, but it can be done.
Codeblocks is not a compiler, but an IDE, that can use different compilers.
The most common one is MinGW.
To complie with minGW so that all the standard libraries are statically linked you shold configure your project (see "project settings") so the the linker options include the -static flag.
You can even be more specific by stecifying
-static-libgcc
-static-libstdc++
There are a lot of open source C/C++ projects, most of them can be compiled using "make" in Linux. Is there any easy way to export this to an IDE, for example Microsoft Visual C++, CodeBlock, or Eclipse?
Even if it is an involved work, is there any step by step help for doing that?
Thanks for the help.
TJ
Considering that most (if not all) of the IDEs support importing a makefile or cmake based project, that should be a no-brainer.
Be careful about configure scripts though, as they generally do important stuff not supported automatically by an IDE.
In fact, build systems like cmake, premake and scons were invented because there was no standard way for an IDE to know what a script is doing. (That, while sacrificing flexibility, makes the system standard.)
What is a good alternative to Makefile on windows?
I'm compiling a collection of c++ files (.cpp's and .h's) using cl.exe.
I'd rather not use Makefile, as I want to minimise the amount of 3rd party utilities people will need to build my application.
Drew J. Sonne.
VisualStudio comes with nmake which would not require any 3rd party tools.
MSBuild, the Microsoft build system. It's the XML-based build system used by Visual Studio. If you have Visual C++ installed, you have MSBuild installed.
Visual Studio project files are just MSBuild files, so anything you can do in Visual Studio with project files, you can do by hand (or vice-versa; you can build Visual Studio projects on the command line).
I would think that depends on which C++ compilers you are supporting for Windows. If you are exclusively targetting Visual Studio users then simply providing the necessary project files should do the trick as your users can either open them in the IDE or use devenv.exe/msbuild.exe to build your project via the command line. In this case, my suggestion would be to provide the project files for the oldest version of Visual Studio that you support as the newer ones will be able to convert the files to the format they require.
It gets a little more tricky if you are trying to support other C++ compilers for Windows also. Either you'll have to provide project files for all of their IDEs which can be tricky if you don't have access to all of them, or you'll have to go for the lowest common denominator, which would be the simplest Makefile possible and hope that most programmers will have make installed, which isn't an unreasonable assumption.
If your software requires the Boost libraries, another approach would be to provide a set of .jam files as most programmers who have Boost probably have bjam floating around back from when they built Boost. While bjam isn't quite as simple as make, it does have the major advantage that it already knows how to handle multiple compilers. But I would only consider bjam if the software distributed required Boost, otherwise it's another unwanted dependency.
I have an old Borland project which I would like to port to Visual Studio 2008. Is there a way to dump, in a human-readable format, the source file, compile options and dependency information from a .ide file?
I'd like something a bit more comprehensive than the 'Generate Makefile' option.
I think it will be easier just to create a new project in Visual Studio and then add all your source files and libraries into it.
I don't think Visual Studio supports OWL (or any Borland libraries).
If this is a VCL application, options and settings are the least of your concerns, since the VCL API is completely different from MFC.
A lot of the Borland compiler options are actually to provide compatibility with MFC. Other than that there isn't actually much overlap in the compiler options.
I occasionally provide Visual Studio 'solution' versions of my Borland projects to colleagues, and normally is simply a matter of selection the .cpp files in the solution and setting any global defines (these is console mode programs mind you, no GUI).
The greater issue is minor inconsistencies in stream classes,
values.h and deprecated functions that Microsoft has dropped.
That is, _stricmp(), _chdir(), _mkdir() _getcwd() instead of stricmp() chdir() mkdir() getcwd(), etc...
I have generally not found the various Borland generated makefiles very compatible with any other compiler (or even with the Borland compiler for that matter).
I don't know about Borland 5, 6 or latest compilers (latest version I've used is Borland C++ 3.1 back in 1994/95 ...), but if you have the chance to generate a Makefile maybe the best solution is to use that Borland makefile to write a NMAKE compatible makefile by hand, if it's not too large.
Another option is to manually import the header, source files and edit the project (compatibilize source and compilation settings) until the build is successful. I think this can be achieved in a short time.
To what dependencies is your project tied to? VCL? MFC? Just standard libs?