Development

Developing GnuCash Code

• See Building for more details on how to build the program from source code.
• See Development_Process for
• We are in the last stage of converting source code version control from Subversion to Git, which we intend to complete shortly after releasing GnuCash version 2.6 at the end of 2013. New contributors should follow the git Git instructions for cloning the repository and preparing patches. Any current developers still using subversion should switch to git for most of their work as soon as possible in order to be ready for the final conversion.

• Please subscribe to the Mailing Lists and introduce yourself to the development team. You can also hang out on IRC, but that isn't required.
• Read the two files HACKING and README.svn.
• Now try your hand at one of the outstanding bugs in Bugzilla, something from the WishList or your own pet peeve. Please consider adding unit tests (see Testing) for features where applicable.
  • The coding style was last discussed on the gnucash-devel ML.
  • If your code will contain textual output for the user, have a look at Translation: Tips for Developers.
  • If your code adds or changes some functionality, do not forget the documentation:
    • We use DOxygen to document the sources, including the C API. Details about our use are on the Doxygen wiki page.
    • Try to keep the README files and that in src/doc up to date.
    • Update the relevant sections in help and guide.
• Once you have your changes written and well tested - make check will run a bunch of tests -, you'll want to submit it so that someone with commit privilege can add it to the official sources. First, make a patch:
  • Git is best. See the patch instructions.
  • If you're using Subversion, you can create a patch with

 svn diff

• • If there's already a bug about it in Bugzilla, just attach the patch to the bug. Be sure to check the "patch" checkbox on the attachment form.
  • If there isn't a bug already (be sure to search!), it really works best if you create a new one to attach your patch to.
    • Describe the problem or improvement that your patch addresses in the initial comment.
    • If you use Git, open the bug before you make your patch so that you can include the bug number in the commit message.
  • If there isn't a bug already and the patch is trivial, you can send it to the gnucash-devel mailing list (though we really do prefer patches to go to Bugzilla).
    • Please attach the patch to the email, don't inline it in the message, even if you used git format-patch and it made a pretty email for you.

Tools

Text editors / IDE:

• Most developers seem to have used Emacs as IDE.
• Additionally there are some experiences with Eclipse.
• Some are using qtcreator.

Build system:

• Gnucash uses the Autotools as build system
• Additionally there are some experiments with CMake, see Cutecash