This is the first of a series of posts about developing desktop GUI applications that run on the computer platforms that I most commonly use:
- Windows – all versions
- Gnu/Linux – all distributions of Gnu/Linux
- BSD – OSs derived from BSD Unix, including FreeBSD, NetBSD and OpenBSD
This post is about the setup that I prefer in these environments, explaining the reasons for my choices. Further posts will go into the details of how to setup each platform and then use the development tools to develop cross-platform applications.
My first priority is that I want identical code to run on all platforms. In practice this means I need to use a cross-platform framework to manage the complexity of the differences between operating systems and particularly the GUI elements. It is quite impractical to try to target all operating systems directly.
Secondly, this is to be a high-performance application using compiled code. Interpreted code still does not really deliver the performance that a data-intensive application requires.
Thirdly, I want identical working environments on all platforms. I don’t want to be constantly adapting to different working environments. For this reason I reject the use of platform-specific IDEs such as Visual Studio, then using a different IDE on each platform – it is possible to do this with the cross-platform framework suggested here, it’s just not my choice to do so.
I have chosen wxWidgets as my framework for reasons I will explain later in this post.
wxWidgets, is written in C++ so that is a natural choice for the compiled language. There are framework bindings to other languages, but these add unnecessary complication to the development process with little gain.
My preference is to have the same development toolsets on both platforms. I have found that, in practice, this means using open-source software which has been ported to all platforms, or, to put it another way, Unix tools which have been ported to Windows, because that has been the way that open source development tools have tended to evolve.
Over the years I have settled on the following combination of software:
- Gnu make tools
- Gnu C++ compiler
- Gnu Emacs editor
- wxWidgets framework
The history of these tools coming from various Unix-like systems means that it is relatively easy to setup the Linux and BSD platforms, somewhat harder to setup the Windows platform to match.
So, why this choice of tools? I’ll start with the framework because that choice tends to drive the other choices.
There are several cross-platform GUI frameworks available and any search of the web will reveal endless arguments about which is “best”.
I don’t intend to join in with those arguments because they are tediously repetitive and ultimately pointless. There is no such thing as a best of anything. Every solution to any real problem of any complexity is a mess of trade-offs and compromises. So you just pick the solution that feels right and get on with the job.
I chose wxWidgets because I find it simple and intuitive to use. In other words, it tends to work in the way that I expect a GUI framework to work, even though that can be a clumsy way at times. In my mind intuitive beats clever any day, and beats complicated by miles.
It is also reasonably complete. It provides the widgets you need for most desktop applications. It also includes cross-platform routines for accessing low-level operating system resources – file-system access, threads, sockets etc. So the whole application is cross-platform, not just the GUI.
It is also pretty simple to build. There are no complicated setup or configuration steps to make it work. This means you have several options for building your application, so can choose the one that suits you best. For example, I have built wxWidgets with three different development toolkits on Windows (MinGW, Cygwin and Visual Studio), and the documentation lists six possibilities for that platform alone. This inspires confidence for me to believe that it will be relatively easy to build and use on other platforms than the two I am choosing should I ever need to expand the set of supported platforms.
wxWidgets is currently ported to: Windows (NT onwards), Unix-like operating systems such as Linux, BSD, Solaris, AIX, HP-UX and MacOSX.
The main website for wxWidgets is at http://www.wxwidgets.org/.
I don’t use an IDE in the sense most people mean it because I don’t relate well to them. The emphasis in most IDEs is on providing visual editors for the GUI elements – yet this is not necessarily the best way to generate GUIs and I find most visual editors are a battle to use. Usually an IDE includes a fairly poor text editor which is not much better than Notepad. Yet typically less than 10% (and probably much less) of an application’s development is GUI elements, nearly all the work is coding. I’d rather have a good text editor and have to spend a bit more effort on the GUI elements.
Of course, I’m not saying that other approaches don’t have anything to offer. I would love Visual Studio’s Intellisense auto-completion in Emacs. But Visual Studio is Windows-only so doesn’t fit the criteria for a cross-platform development environment. In the end, using Emacs is easy to set up and get started and does most things well enough for me not to need to look elsewhere.
GNU Emacs has been my editor of choice since my early days of programming. It is a powerful text editor, which also has built-in IDE features, such as integrated compilation, automatic jump-to-error for compiler errors, integrated debugger, integrated version control etc. So it can be used as a complete development environment, though one lacking a visual editor.
Again, I don’t want to get involved in any “discussion” about whether it is the “best”. It suits me and that’s enough for me.
It is available on a wide range of platforms, including all those of interest to me. So it is possible to have identical development environments on all platforms.
The main website for Emacs is at http://www.gnu.org/software/emacs/.
Gnu C++ Compiler (g++)
The choice of C++ is really made by the choice of wxWidgets as the framework. OK, it has language bindings to, for example, Python, but this to me just adds complexity. So I prefer to work in C++ throughout. It is possible to build wxWidgets with several different C++ compilers, but I prefer to stick with one compiler across all platforms because that minimises the possible problems. It also means I can use a single build system on all platforms (see next section). I prefer Gnu’s g++ compiler because I have been using it for something like 20 years, it is familiar, and is available on a wide range of platforms. It is the native compiler on Linux, so is usually installed already. It is typically installed by default on BSD and other Unix-like OSs too. There are several Windows versions available, which I will address in more detail in the separate post on Windows Setup.
Having said this, I have generally found that code developed for wxWidgets using Gnu compilers will compile easily in Visual Studio. So you could go that route – Gnu tools on Linux, Microsoft tools on Windows, and there will be few problems. The main problem with this approach is maintaining Visual Studio’s project files!
The main website for the Gnu Compiler Collection is at http://www.gnu.org/software/gcc/.
Gnu Make Tools (make)
The natural complement to using g++ for compilation is to use Gnu’s “make” command for building the application.
However, for a large application, “make” requires quite a complex Makefile to drive the build. I addressed this problem years ago with my makefiles project which supplies a standard set of rules suitable for building most projects provided the code is organised according to some simple rules. There’s an extension to this project which, by adding a single line of code to a Makefile, builds a wxWidgets project.
To work, “make” requires a Unix-like scripting shell. This is always available on Linux and other Unix-like OSs, and is core to their workings. There are several ports of Gnu’s shell to Windows, so it is possible to use Gnu “make” on Windows. More on this in the Setup guide to Windows.
The website for Gnu make is at http://www.gnu.org/software/make/.
The following posts cover setting up development environments as described here on specific platforms. The aim is to have as near-identical a setup on all platforms as possible: