For operating systems where no binary is provided or if you want the latest development version, you will have to build it from source. The code should be compilable on any system with ISO C++14. It's tested on Linux, Mac OS/X, and Windows cross compilers. Less frequently, someone will build on MSVC, FreeBSD, OpenBSD, Solaris, etc. Both Clang/LLVM and GNU C++ are regularly exercised via automation.
You can grab a release from the GPSBabel download page, but if you're going to be doing any development, you'll find that working from the GPSBabel Github repo is easier. Checkouts via Git, HTTPS, SSH, and Subversion are supported.
There are external requirements for bulding.
- Qt
Qt version 5.9 or newer is required for all builds. MacOS and Windows users can download binaries from Qt Downloads Fedora or CentOS users may need to 'yum install qt-devel'. Optionally, use qt5-base. When in doubt, 'yum search qt' or 'yum search qt5' may help you find the correct package name. Ubuntu users may need to 'apt-get install qtbase5-dev'. Package names and versions in Linux frequently change, so you may need to ask your Linux vendor for help or look in tools/Docker* for inspiration for our automated builds that use Docker.
- libusb
is needed to communicate with use with older USB Garmins. For MacOS, we use an included copy. Fedora users may need to 'yum install libusb-devel'. Ubuntu users may need to 'apt install libusb-dev' or look in tools/Docker* for inspiration from our automated Docker builds.
Parts of GPSBabel have been public since 2002, with some of the original design and original code came from 2001. It was originally in C89, not C++ and while we strongly encourage modern C++ code where we can use it, we've not gone back to those older formats - some of which we don't have the hardware to test and have fallen out of touch with original authors - and rewritten them in Modern C++ style. There are this void*'s everywhere, C String use, gross buffer abuse, and other things that look more like a C program from the 80's than a C++ program of modern date. Code that's earned it's own wings can continue to fly with us as long as it passes the tests we have. We've additionally not enforced style rules as strongly across modules as we could have. Fixing both of these is a goal for us in 2020.
Qt provides a lovely IDE (Integrated Development Evironment) with an
editor and debugger. Its use is strongly encouraged for those new to C++.
Once you have Qt correctly installed, just opening either the
GPSBabel.pro or gui/app.pro files from
the OS file launcher (e.g. a double click in MacOS while seeing it in Finder)
or from a File->Open in an already-running instance of Qt Creator is the fastest and easiest way for most
people to get to development because it handles things like build dependencies
changing and class and method compilation.
A path of low resistance for some users is to use the Qt build files (*.pro) and compiler chain, but use the command line. If you type qmake in our working directory, it will build a "native" Build file (Makefile, XCode, Visual Studio) which you can use for development.
Those familiar with UNIX-y open source packages may be more comfortable with configure. In most cases, the code is as simple to build as running:
./configure && make
There are additional flags that can be passed to configure to customize your build of GPSBabel.
./configure --help
lists all the supported options, but of interest we have:
--disable-shapefile Excludes the shapefile support.
--disable-csv Excludes all support for our something-separated formats.
--disable-filters Excludes all filter support.
--with-doc=dir Specifies that the doc should be created and installed in dir.
--without-libusb Disables use of libusb, even it's it's available.
--with-zlib=(included)|system|no By default, we use our own version of zlib. If you specify system the system zlib is used. A value of no (or --without-zlib) disables zlib.
There are some makefile targets that are useful mostly to the GPSBabel maintainers that appear only in the configure-generated Makefiles. Their presence is considered mostly a TODO bug and those items should be migrated to stand-alone tools.