I am totally new to CMake and compiled languages for that matter. I have seen this question and answer. But I still don't fully understand what CMake is.
I am coming from a nodeJs/Javascipt environment, therefore if I could know a CMake equivalent in the nodeJs/Javascipt environment it would really help me understand what it is.So... Is CMake an equivalent of npm?
No, citing from Wikipedia:
CMake is a cross-platform free and open-source software tool for managing the build process of software using a compiler-independent method. It supports directory hierarchies and applications that depend on multiple libraries. It is used in conjunction with native build environments such as Make, Qt Creator, Ninja, Apple's Xcode, and Microsoft Visual Studio. It has minimal dependencies, requiring only a C++ compiler on its own build system.
JavaScript is an interpreted language, that means NodeJS/Browsers read and understand the code and execute it directly. For example C is built via a compiler (that reads and understands the code before execution) to Machine code (that does not need to be understand because it's the native language from your processor) and can be executed faster. CMake simplifies calling the Compiler, linking libraries (something like setting up require) and more for all files. Altough sometimes using babel, webpack and others via npm run is called 'building'.
I'm currently investigating cmake to allow automatic building on the Win32 platform. For all runtimes and libraries I'd like to build, Visual Studio (2008/2010) projects do allready exist.
I've come across cmake, but I'm unsure if I really need it. As the documentation says, cmake generates VS projects and they then can be built e.g. using MSBuild.
As the projects itself allready do exist (and build nicely via the IDE or MSBuild on the cmd line), what do I need and use cmake for? Just for directory/project folder traversal? Build failure reporting?
Regards,
Paul
Well, strictly speaking you do not need it. However, it does give you a few advantages:
The idiomatic way to use CMake, forces you to use out-of-source builds. Arguable, but I am personally convinced that these keep you source-repository very clean.
You can support multiple visual studio versions (with the out-of-source builds). Perhaps it will be a little easier to port your project to other compilers (from MinGW -> Linux GCC).
With the find_package and config.cmake files, and a large number of available findXXX modules, CMake makes it a lot easier to "import" third-party libraries into your build-chain.
You don't need it. Cmake is only useful if you are trying to keep the same source code able to build in multiple platforms and compilers. If you are simply building using the microsoft stack you have no need of it.
Have a C++ source I probably can't build in Code::Blocks. If I use it as an editor, would it be helpful in gaining understanding of the code? (Like Intellisense).
How does it compare to Visual Studio in this respect?
How should I go about doing it?
Can it somehow utilize gdb information (When I run it in gdb, there is a lot of information available)
It is Linux gcc/Makefile based.
The main executable is in one directory, but there are many includes, libraries etc.
If I just included all sources I would get sources for other executables (with similar code).
I expect to increase my understanding about where things are located over time.
Note 1: This is Linux, but I can easily edit on Windows. And I am trying to build under Cygwin.
Code::Blocks sounds too light weight for your tastes. Try NetBeans. It has very good hinting tools, doesn't have the infamous copy+paste bug, Its easier to navigate files, and can deal with makefiles better then C::B. Additionally it has a nice interface for debugging, and an exceptional one for performance monitoring.
I would reccomend you install a linux distro through WUBI and forgo using Windows.
I have used NetBeans, Eclipse, Visual Studio, Code::Blocks, and CodeLite. I don't normally write software under Windows anymore, but when I did CodeLite was the most elegant one I found. Debugging was a snap (mingw + GDB), all the meta information about your project is stored in an sqlite db (which I think is a great design), and it supports makefiles.
I think NetBeans would work great as well, but definitely give CodeLite a shot.
http://www.codelite.org/
I have been looking for pros & cons of Autotools and CMake. But I would like to know opinions from people having used one (or both) of these tools for projects.
I used Autotools very basically a year ago and I know that one of the good points is that it relies on shell scripting, thus it does not need to be installed to be run and uses portable shell scripting. But it looks like it is too unix oriented, and it would not be possible to run the configure file on Windows.
I have now to choose a build system tool for an open source project that will have to be compiled for at least Linux & Windows. It is written in C++, and uses a Qt GUI front-end, the rest of it is "generic".
Thanks for you help.
Updated 16th of January 2019: Refined advice as tools evolve.
I have used autotools before for a considerable amount of time.
Currently I make intensive use of meson and cmake only when I need it.
Some personal advice:
for big teams, stick to CMake if you want to make use of the generators for XCode. If you do not need it, I would use Meson directly. Meson, as of version 0.49, also supports finding CMake configuration files (though I did not test yet how well this works). Also, Visual Studio seems to be sufficiently well-supported at this point in time, though, again, I did not try myself. The advantage of CMake is that it has Visual Studio integration.
Drop autotools. Meson covers well everything already. Their cross-compilation model is amazingly understandable. In CMake, last time I checked, everything was quite more difficult.
I have also tried scons, waf, and tup.
The most full-featured, cross-platform system, is CMake, but the DSL from meson will be easier to use for people used to python and others. Meson is starting to support VS also (a VS2015 generator) and some projects already have experimental support for it, for example gstreamer. Gstreamer is compiled in windows as well with meson. Right now there is VS2015 generator and VS2017 but I did not try myself the generators lately. As of meson 0.37.1 needed some work, but they are improving them and current version is already 0.40.
Meson
Pros:
The DSL does not get in the way at all. In fact, it is very nice and familiar, based in python.
Well-thought cross compilation support.
The objects are all strongly typed: you cannot make string substitution mistakes easily, since objects are entities such as 'depencency', 'include directory', etc.
It is very obviuos how to add a module for one of your tools.
Cross-compilation seems more straightforward to use.
Really well-thought. The designer and main writer of Meson knows what
he talks about very well when designing a build system.
Very, very fast, especially in incremental builds.
The documentation is 10 times better that what you can find in cmake. Go visit http://mesonbuild.com and you will find tutorial, howtos and a good reference. It is not perfect but it is really discoverable.
Cons:
Not as mature as CMake, though, I consider it already fully usable for C++.
Not so many modules available, though, gnome, qt and the common ones are already there.
Project generators: seems VS generator is not working that well as of now. CMake project generators are far more mature.
Has a python3 + ninja dependency.
Cmake
Pros:
Generates projects for many different IDEs. This is a very nice feature for teams.
Plays well with windows tools, unlike autotools.
Mature, almost de-facto standard.
Microsoft is working on CMake integration for Visual Studio.
Cons:
It does not follow any well known standard or guidelines.
No uninstall target.
The DSL is weird, when you start to do comparisons and such, and the strings vs list thing or escape chars, you will make many mistakes, I am pretty sure.
Cross compilation sucks.
Autotools
Pros:
Most powerful system for cross-compilation, IMHO.
The generated scripts don't need anything else than make, a shell and, if you need it to build, a compiler.
The command-line is really nice and consistent.
A standard in unix world, lots of docs.
Really powerful command-line: changing directories of installation, uninstall,
renaming binaries...
If you target unix, packaging sources with this tool is really convenient.
Cons:
It won't play well with microsoft tools. A real showstopper.
The learning curve is... well... But actually I can say that CMake was not that easy either.
The use of recursive make is pervasive in legacy projects. Automake supports non-recursive builds, but it's not a very widely used approach.
About the learning curve, there are two very good sources to learn from:
The website here
The book here
The first source will get you up and running faster. The book is a more in-depth discussion.
From Scons, waf and tup, Scons and tup are more like make. Waf is more like CMake and the autotools. I tried waf instead of cmake at first. I think it is overengineered in the sense that it has a full OOP API. The scripts didn't look short at all and it was really confusing for me the working directory stuff and related things. At the end, I found that autotools and CMake are a better choice. My favourite from these 3 build systems is tup.
Tup
Pros
Really correct.
Insanely fast. You should try it to believe it.
The scripting language relies on a very easy idea that can be understood in 10 minutes.
Cons
It does not have a full-featured config framework.
I couldn't find the way to make targets such as doc, since
they generate files I don't know of and they must be listed in the output before being generated, or at least, that's my conclusion for now. This was a really annoying limitation, if it is, since I am not sure.
All in all, the only things I am considering right now for new projects is are Cmake and Meson. When I have a chance I will try tup also, but it lacks the config framework, which means that it makes things more complex when you need all of that stuff. On the other hand, it is really fast.
I would not recommend autotools for Windows. Use CMake.
Why? Windows doesn't have a native sh.exe, and the emulation is slow. It's also very easy to get configury stuff wrong. I'm not saying it's impossible in CMake, but CMake surely abstracts more away, so you worry about less. CMake documentation can be a bit hard to read, but once it's set up, you should be fine for all toolchains ever supported by CMake. CMake also integrates testing, packaging etc...
Autotools is slow on Windows, does not work easily with MSVC, and has weird quirks with Windows (and other OSes) that are hard to debug, and hard to fix. libtool also sucks on Windows, where it often refuses to build a shared library even, if you think it should and could. Toolchain relocation issues are also prevalent with libtool, which may look at the wrong files in a user's toolchain. CMake is a lot easier in this regard. It assumes normal things about the target platform and creates generic and good build instructions.
Also, CMake has coloured output :) and nice progress percentages.
PS: I just have some experience with CMake and autotools on Windows as a user. CMake tends to work, autotools tends to bite your ear off when you're not looking, and smile at you when it fails due to some strange error...
What would be the best way to write Objective-C on the Windows platform?
Cygwin and gcc? Is there a way I can somehow integrate this into Visual Studio?
Along those lines - are there any suggestions as to how to link in and use the Windows SDK for something like this. Its a different beast but I know I can write assembly and link in the Windows DLLs giving me accessibility to those calls but I don't know how to do this without googling and getting piecemeal directions.
Is anyone aware of a good online or book resource to do or explain these kinds of things?
Expanding on the two previous answers, if you just want Objective-C but not any of the Cocoa frameworks, then gcc will work on any platform. You can use it through Cygwin or get MinGW. However, if you want the Cocoa frameworks, or at least a reasonable subset of them, then GNUStep and Cocotron are your best bets.
Cocotron implements a lot of stuff that GNUStep does not, such as CoreGraphics and CoreData, though I can't vouch for how complete their implementation is on a specific framework. Their aim is to keep Cocotron up to date with the latest version of OS X so that any viable OS X program can run on Windows. Because GNUStep typically uses the latest version of gcc, they also add in support for Objective-C++ and a lot of the Objective-C 2.0 features.
I haven't tested those features with GNUStep, but if you use a sufficiently new version of gcc, you might be able to use them. I was not able to use Objective-C++ with GNUStep a few years ago. However, GNUStep does compile from just about any platform. Cocotron is a very mac-centric project. Although it is probably possible to compile it on other platforms, it comes XCode project files, not makefiles, so you can only compile its frameworks out of the box on OS X. It also comes with instructions on compiling Windows apps on XCode, but not any other platform. Basically, it's probably possible to set up a Windows development environment for Cocotron, but it's not as easy as setting one up for GNUStep, and you'll be on your own, so GNUStep is definitely the way to go if you're developing on Windows as opposed to just for Windows.
For what it's worth, Cocotron is licensed under the MIT license, and GNUStep is licensed under the LGPL.
You can use Objective C inside the Windows environment. If you follow these steps, it should be working just fine:
Visit the GNUstep website and download GNUstep MSYS Subsystem (MSYS for GNUstep), GNUstep Core (Libraries for GNUstep), and GNUstep Devel
After downloading these files, install in that order, or you will have problems with configuration
Navigate to C:\GNUstep\GNUstep\System\Library\Headers\Foundation1 and ensure that Foundation.h exists
Open up a command prompt and run gcc -v to check that GNUstep MSYS is correctly installed (if you get a file not found error, ensure that the bin folder of GNUstep MSYS is in your PATH)
Use this simple "Hello World" program to test GNUstep's functionality:
#include <Foundation/Foundation.h>
int main(void)
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSLog(#"Hello World!.");
[pool drain];
return;
}
Go back to the command prompt and cd to where you saved the "Hello World" program and then compile it:2
gcc -o helloworld.exe <HELLOWORLD>.m -I /GNUstep/GNUstep/System/Library/Headers -L /GNUstep/GNUstep/System/Library/Libraries -std=c99 -lobjc -lgnustep-base -fconstant-string-class=NSConstantString
Finally, from the command prompt, type helloworld to run it
All the best, and have fun with Objective-C!
NOTES:
I used the default install path - adjust your command line accordingly
Ensure the folder path of yours is similar to mine, otherwise you will get an error
Also:
The Cocotron is an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation.
http://www.cocotron.org/
WinObjC? Windows Bridge for iOS (previously known as ‘Project Islandwood’).
Windows Bridge for iOS (also referred to as WinObjC) is a Microsoft open source project that provides an Objective-C development environment for Visual Studio/Windows. In addition, WinObjC provides support for iOS API compatibility. While the final release will happen later this fall (allowing the bridge to take advantage of new tooling capabilities that will ship with the upcoming Visual Studio 2015 Update),
The bridge is available to the open-source community now in its current state. Between now and the fall. The iOS bridge as an open-source project under the MIT license. Given the ambition of the project, making it easy for iOS developers to build and run apps on Windows.
Salmaan Ahmed has an in-depth post on the Windows Bridge for iOS http://blogs.windows.com/buildingapps/2015/08/06/windows-bridge-for-ios-lets-open-this-up/ discussing the compiler, runtime, IDE integration, and what the bridge is and isn’t. Best of all, the source code for the iOS bridge is live on GitHub right now.
The iOS bridge supports both Windows 8.1 and Windows 10 apps built for x86 and x64 processor architectures, and soon we will add compiler optimizations and support for ARM, which adds mobile support.
I have mixed feelings about the Cocotron project. I'm glad they are releasing source code and sharing but I don't feel that they are doing things the easiest way.
Examples.
Apple has released the source code to the objective-c runtime, which includes properties and garbage collection. The Cocotron project however has their own implementation of the objective-c runtime. Why bother to duplicate the effort? There is even a Visual Studio Project file that can be used to build an objc.dll file. Or if you're really lazy, you can just copy the DLL file from an installation of Safari on Windows.
They also did not bother to leverage CoreFoundation, which is also open sourced by Apple. I posted a question about this but did not receive an answer.
I think the current best solution is to take source code from multiple sources (Apple, CocoTron, GnuStep) and merge it together to what you need. You'll have to read a lot of source but it will be worth the end result.
I'm aware this is a very old post, but I have found a solution which has only become available more recently AND enables nearly all Objective-C 2.0 features on the Windows platform.
With the advent of gcc 4.6, support for Objective-C 2.0 language features (blocks, dot syntax, synthesised properties, etc) was added to the Objective-C compiler (see the release notes for full details). Their runtime has also been updated to work almost identically to Apple's own Objective-C 2.0 runtime. In short this means that (almost) any program that will legitimately compile with Clang on a Mac will also compile with gcc 4.6 without modification.
As a side-note, one feature that is not available is dictionary/array/etc literals as they are all hard-coded into Clang to use Apple's NSDictionary, NSArray, NSNumber, etc classes.
However, if you are happy to live without Apple's extensive frameworks, you can.
As noted in other answers, GNUStep and the Cocotron provide modified versions of Apple's class libraries, or you can write your own (my preferred option).
MinGW is one way to get GCC 4.6 on the Windows platform, and can be downloaded from The MinGW website. Make sure when you install it you include the installation of C, C++, Objective-C and Objective-C++. While optional, I would also suggest installing the MSYS environment.
Once installed, Objective-C 2.0 source can be compiled with:
gcc MyFile.m -lobjc -std=c99 -fobjc-exceptions -fconstant-string-class=clsname (etc, additional flags, see documentation)
MinGW also includes support for compiling native GUI Windows applications with the -mwindows flag. For example:
g++ -mwindows MyFile.cpp
I have not attempted it yet, but I imagine if you wrap your Objective-C classes in Objective-C++ at the highest possible layer, you should be able to successfully intertwine native Windows GUI C++ and Objective-C all in the one Windows Application.
Check out WinObjC:
https://github.com/Microsoft/WinObjC
It's an official, open-source project by Microsoft that integrates with Visual Studio + Windows.
If you just want to experiment, there's an Objective-C compiler for .NET (Windows) here: qckapp
You can get an objective c compiler that will work with Windows and play nice with Visual Studio 2008\2010 here.
open-c flite
Just download the latest source. You don't need to build all of CF-Lite there is a solution called objc.sln. You will need to fix a few of the include paths but then it will build just fine. There is even a test project included so you can see some objective-c .m files being compiled and working in visual studio. One sad thing is it only works with Win32 not x64. There is some assembly code that would need to be written for x64 for it to support that.
A recent attempt to port Objective C 2.0 to Windows is the Subjective project.
From the Readme:
Subjective is an attempt to bring Objective C 2.0 with ARC support to
Windows.
This project is a fork of objc4-532.2, the Objective C runtime that
ships with OS X 10.8.5. The port can be cross-compiled on OS X using
llvm-clang combined with the MinGW linker.
There are certain limitations many of which are a matter of extra
work, while others, such as exceptions and blocks, depend on more
serious work in 3rd party projects. The limitations are:
• 32-bit only - 64-bit is underway
• Static linking only - dynamic linking is underway
• No closures/blocks - until libdispatch supports them on Windows
• No exceptions - until clang supports them on Windows
• No old style GC - until someone cares...
• Internals: no vtables, no gdb support, just plain malloc, no
preoptimizations - some of these things will be available under the
64-bit build.
• Currently a patched clang compiler is required; the patch adds
-fobjc-runtime=subj flag
The project is available on Github, and there is also a thread on the Cocotron Group outlining some of the progress and issues encountered.
Get GNUStep here
Get MINGW here
Install MINGW
Install GNUStep
Then Test
If you are comfortable with Visual Studio environment,
Small project: jGRASP with gcc
Large project: Cocotron
I heard there are emulators, but I could find only Apple II Emulator http://virtualapple.org/. It looks like limited to games.
First of all, forget about GNUStep tools. Neither ProjectManager nor ProjectCenter can be called an IDE. With all due respect, it looks like guys from GNUStep project are stuck in the late 80-s (which is when NeXTSTEP first appeared).
Vim
ctags support Objective-C since r771 (be sure to pick the pre-release 5.9 version and add --langmap=ObjectiveC:.m.h to the command line, see here), so you'll have decent code completion/tag navigation.
Here's a short howto on adding Objective-C support to Vim tagbar plugin.
Emacs
The same applies to etags shipped with modern Emacsen, so you can start with Emacs Objective C Mode. YASnippet will provide useful templates:
and if you want something more intelligent than the basic tags-based code completion, take a look at this question.
Eclipse
CDT supports Makefile-based projects:
-- so technically you can build your Objective-C projects out of the box (on Windows, you'll need the Cygwin or MinGW toolchain). The only problem is the code editor which will report plenty of errors against what it thinks is a pure C code (on-the-fly code checking can be turned off, but still...). If you want proper syntax highlighting, you can add Eclim to your Eclipse and enjoy all the good features of both Eclipse and Vim (see above).
Another promising Eclipse plugin is Colorer, but it doesn't support Objective-C as of yet. Feel free to file a feature request though.
SlickEdit
SlickEdit, among other features of a great IDE, does support Objective-C. While it is fairly complex to learn (not as complex as Emacs though), I believe this is your best option provided you don't mind purchasing it (the price is quite affordable).
Additionally, it has an Eclipse plugin which can be used as an alternative to the stand-alone editor.
KDevelop
Rumor has it there exists a KDevelop patch (15 year old, but who cares?). I personally don't think KDevelop is feature-superior compared to Emacsen, so I wouldn't bother trying it.
The above also applies to Objective-C development on Linux, since all of the tools mentioned are more or less portable.
As of 2021, the GNUstep Windows MSVC Toolchain allows to integrate Objective-C code in any Windows app, including Visual Studio projects using LLVM/Clang. This includes support for Automatic Reference Counting (ARC) and Objective-C 2.0 features such as blocks.
The project includes the Foundation, CoreFoundation, and libdispatch libraries from GNUstep. It does currently not include any UI framework such as AppKit or UIKit, but it can be used to e.g. write a Windows-specific UI with cross-platform business logic written in Objective-C.