Readme First for GPSTk Developers


The Development web is where discussion is held on the development of GPSTk library functions and applications. Everybody who is interested in contributing to enhance the GPSTk is invited to collaborate in this web. You can subscribe using the WebNotify page (or with the Subscribe Topic button on every page) to get daily email with all changes in the web. Also see our GPSTkEmailLists and subscribe to the gpstk-devel list. We have an ever diverse development community led by a friendly CoreTeam.

How to Find, Where to Post

The development is growing every day. For the unfamiliar, it can seem a little daunting to try and find specific info, or figure out where to post. Not so! Although wikis are constantly in the midst of cleaning and decluttering, the Development web is a most orderly place. Here's the how-to:

  • Searching is fast, comprehensive, easy: In fact, those are core TWiki design specs. Use the Search link on the toolbar at the top of every page. You can perform a simple full-text keyword search, or construct a complex regular expression. Either an alphabetical index or keyword search on topic titles can be useful in finding topics quickly.
    IDEA! Hint: To get a list of topics on a subject like "xml", type the name into the GoBox. It's fast and easy.

  • Check under Development categories: The Development web has a set of Categories that link to a quick-scan list of Development page categories. Development topics may be classified: click on a heading to get full list topics. (And you can come straight back to this page from the toolbar, too!)

  • Browse from page-to-page: Less structured than searching and clicking categories, but often more useful, simply start on a page that interests you, and follow the inline links - a major Wiki feature is the use of meaningful, easily-created WikiWord links in the text, leading to all sorts of cross-topic threads!

  • Start from WebHome: On the Development home page, you'll find the topic categories, along with other key pages, some of which change over time: special projects, announcements, new release notices, and more. All fully described. Click Development on the left of that top toolbar.

POSTING is easy once you know the Development setup: Read GoodStyle for a basic text entry primer. Click Edit on any page, and you're off. You'll see a WebForm with the page classification: change it if it's wrong, fill it in for a new page. The Development web has a SignatureNetiquette. Use your judgment whether to add to an existing discussion, or start a fresh topic. It's that simple.

GPSTk Mission

"GPSTk mission is to be the premier open source library and suite of applications for use and collaboration with the satellite navigation community--to free researchers to focus on research, not lower level coding."

This mission should be kept in mind when contributing to further GPSTk development.

Further development should have this focus:

  • Enhance GPSTk evolutionarily to fit the mission.
  • Easy maintenance is key.
  • KISS (keep it simple) design is preferred over complicated designs.
  • Maintain platform-independence as much as possible
  • Leverage principles of object-oriented programing to ensure the code is modular, extensible, and maintainable
  • Keep the quality as high, e.g. few or no bugs for stable releases

How Can I Contribute?

GPSTk is an Open Source project, and as such relies on the support of users and fans to keep going. So anything you can do to help, is almost certain to be welcome!

There are many ways you can contribute, from simply telling the community your story, through writing applications, or even becoming a fully-fledged core team member. Here are just a few of the more obvious ways you can contribute.

Be an advocate. Tell your friends, tell your colleagues, present papers, use the tool!

Tell the community your success story. Write a page starting at the page GPSTkSuccessStories. There are some examples already there!

If your story isn't a success - and we all know there are some - it's still equally valuable.

Help out with documentation. If you find problems with the documentation, or find it difficult to use, or simply can't find the answer you were looking for, then don't just complain. Go fix it as well!

Crush bugs. Bugs get reported at Bugs. If you are adventurous, you might try your hand at finding a fix, and post that alongside the report! The more relevant information you provide with the report, the more chance there is of there being a fix. Don't forget that your bug may have been reported already, and there might even be a patch to fix it. If you know how to fix a problem, you are very welcome to attach a unified diff to your report (but please make sure it's clear what version of the code it's based on!)

Be a support god. The AskedQuestions is the place to find questions that need to be answered. If you are confident enough, feel free to answer any that you can! The support is an entirely volunteer effort, so the more people who visit and help out, the better.

Contribute brainpower. The Development web is a fertile ground for the seeds of ideas. It's made fertile by the many eyes who read changes to topics, and contribute to the development and refinement of ideas into reality. This isn't onerous; it just means staying aware of what's being discussed and when you think you can contribute, being prepared to speak up. Contributing doesn't just mean voicing opinions, of course. The goal is to refine ideas down to practical solutions, and that requires a positive outlook, and a preparedness to get your hands dirty, even if it's only to refactor (organise) a topic.

And don't forget; the newest contributor often has the freshest ideas!

Become a GPSTk developer. Developers are strongly recommended to work in the GPSTk Git repository, once the ARL Git Server has been set-up; see SoYouWantToBeADeveloper for help in getting set up.

Join the core team. The CoreTeam are people who take on the heavy responsibility of managing the GPSTk development and building releases. They look at contributed changes and decide which changes fit with the GPSTkMission. From there, they build the stable releases of the tool. The CoreTeam also have the last word on the GPSTk architecture and documentation, so it tends to be only the most experienced and adept contributors who are on the core team. If you think you have what it takes to be part of the core team, speak to BryanParsons.

Types of GPSTk Releases

There are three ways you can get GPSTk. You can get stable releases as either precompiled binaries or as source code to compile. If you are brave or want to do development of the GPSTk, you can check out the Git repository, once the ARL Git Server is set-up. Developers sometimes create branches for testing that you might want to use as well. The access to the different versions is described on the GPSTkDownloads.

Release Naming Convention

GPSTk uses the GNU "standard" for naming releases, e.g. gpstk-1.1.07. The first number is a major release identifier, the second is a revision, and the third is a patch level. After the version number will be a descriptor that indicates the contents of the particular file. The following descriptors are used:

src Platform independent source code of the GPSTk.
solaris.sparc Sun Solaris Sparc compiled binaries
linux.x86_64 Linux 64-bit compiled binaries
mac.osx Mac OSX compiled binaries
win32 Microsoft Windows 32-bit compiled binaries
win64 Microsoft Windows 64-bit compiled binaries

Typical work-flow for new features

  • Developers discuss new features in the Development web, one topic per feature. At that time, the topic classification is set to BrainstormingIdea.
  • The discussion continues until the feature is well enough specced to start work.
  • When someone decides to work on a feature, they mark the Development topic as FeatureUnderConstruction.
  • The code will be incrementally checked into Git, so other developers and testers can see it in progress and add their comments/code.
  • All new features should be documented in Documentation web or in Doxygen comments in the source code.
  • Tracking is done in the Development web. When the feature is finished the classification of the topic is set to FeatureDone.
  • Remember, a feature isn't done until it's all done - doc and unit tests as well!


Feedback is appreciated in ReadmeFirstFeedback (and in CodingStandards for that matter)

Adapted from:
Topic revision: r9 - 05 Sep 2013, BryanParsons

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback