Howto become a OpenSync Hacker

This is a quick and dirty introduction in getting involved in the OpenSync project. (Feel free to add useful hints, tips, tricks and any other kind of information about this. Thanks!)

• Subscribe to the project mailing lists:
  Developer and User mailing lists of !OpenSync:
  http://lists.sourceforge.net/mailman/listinfo/opensync-users
  http://lists.sourceforge.net/mailman/listinfo/opensync-devel
  (The developer list gets also every ticket and ticket changes.. very good to track everything.)
  The OpenSync commit mailing list is also quite interesting:
  

http://lists.sourceforge.net/mailman/listinfo/opensync-commits
http://lists.sourceforge.net/mailman/listinfo/opensync-tickets

• Join #opensync on irc.freenode.net
• Write a plugin for your pda, mobile, favorite PIM or whatever
• Document the OpenSync framework (Doxygen, Wiki, Whitepapers, ...)
  • For building the Doxygen Documentation you need to enable CMake option BUILD_DOCUMENTATION and run make DoxygenDoc
  • LaTeX rewrite of Whitepaper is located in http://www.opensync.org/browser/trunk/docs/whitepaper
• Test synchronization plugins write bugreports or add your tested device to DeviceCompatibilityList
• Test the vcard*, vcal, iCalendar, vtodo and vnote converters (also called "vformats")
• Review patchset from Benq-Mobile of Xmpm
• Help us keeping the wiki in a usable state
• Review, reproduce or fix bugs of the OpenSync buglist
• Help other people on the mailing list or IRC with their problems
• Write testcases... troubleshooting guides...
• Spread the word...

Coding

• read Coding Style Guidelines
• read Coding Style Guidelines again
• Build the latest revision of SVN and test latest changes
• Get familiar with the devel-branch of OpenSync devel-branch-0.30
• Start coding for OpenSync in the devel-branch-0.30
• Review the code of OpenSync code and feel free to improve it... every patch is welcome
• Apply for a SVN account or send patches to the -devel where everyone can see it and discuss it.
  • There is also HTTPS SVN WebDAV now - https://svn.opensync.org
  • If you have trouble behind a proxy or plan to commit stuff in a "public" network
• Comment your SVN commits account very well.
• Write unit tests

Unit tests

• Enable the build of unittests:
  • cmake -DOPENYNC_UNITTESTS=ON $SOURCEPATH
  • or toggle the option with ccmake
• Write more unit tests!
• Use code coverage to get inspired for writing unittests
• Check Framework:
  • export CK_FORK=no - disables forking of unit tests (debugging purpose: gdb, valgrind, ...)
• CTest:

  make ExperimentalStart 
  make ExperimentalBuild 
  make ExperimentalMemCheck 
  make ExperimentalTest
  make ExperimentalCoverage 
  make ExperimentalSubmit 
  

  or just call

  make Experimental
  

  or without commiting results to the dashboard

  make test
  

  • Tests results/logfiles are also stored in a directory called "Testing" in the build root directory
  • For code coverage it's required to build with CMAKE_BUILD_TYPE=Profiling (gcc only)
    • Code coverage metrics are available on http://opensync.org/testing you can also generate your own with make Experimental
    • (Offline) Alternatively without committing to the dashboard, install lcov http://ltp.sourceforge.net/coverage/lcov.php and run tests/coverage.sh within the tests source directory - AFTER running your tests. Coverage metrics are available in tests/coverage/html/$DATETIMESTAMP/index.html
  • MemCheck requires valgrind (memcheck)
  • ExperimentalSubmit sends testing results to http://opensync.org/testing/index.php?project=OpenSync#Experimental

Howto debug OpenSync

• Make sure your version of OpenSync is build with tracing
• Learn something about tracing of OpenSync
• OpenSync is not easy to debug with gdb, because of the threads for each plugin, object engine, ...
  • attach the process directly when it is running
  • if you want to debug a plugin with gdb start the osplugin executable in advanced within gdb (see usage of osplugin)
• Hunting memory leaks and other evil stuff with valgrind: http://valgrind.org/docs/manual/QuickStart.html

  valgrind --leak-check=full msynctool --sync yourgroup
  

  • If the plugin (shared module) is part of the backtrace it is likely that the symbols of the plugin calls are lost: (???) Build OpenSync with debug_modules=1. This avoids unloading of shared modules and make debugging more easier.
  • it is also recommended for hunting memory leaks to set G_SLICE to "always-malloc": http://developer.gnome.org/doc/API/2.4/glib/glib-running.html

    export G_SLICE=always-malloc
    

• Learn to debug libsyncml http://libsyncml.opensync.org

FAQ

(Add your question(s) here)