wiki:join/developer
Last modified 2 years ago

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!)

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

  • Join #opensync on irc.freenode.net
  • Check the  Roadmap: assign to yourself Active Tickets for the next milestone (or the one after)
  • Write a plugin for your pda, mobile, favorite PIM or whatever (for now we focus on core components, until 0.40)
  • Document the OpenSync framework (Doxygen, Wiki, Whitepapers, ...)
  • Test synchronization plugins write bugreports or add your tested device to releases/0.2x/docOutdateds/0.2x/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 (in good shape, today!)
  • 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...

Get the Code

  • Subversion: 
    svn co https://svn.opensync.org/trunk
    • Subversion is our primary SCM!
  • GIT SVN mirror of /trunk (read-only!): 
    git clone http://repo.or.cz/r/opensync.git
    • This is an unofficial repository!
    • It's known not to build out of the box!
      • Empty directories in the testsuite are missing (GIT handles content, not file hierarchy)
      • The cmake modules directory is due to the svn:external missing.
        • If you just want to build opensync (without running the tests) from git - get a copy from the cmake/modules directory
  • trunk scripts:

 http://opensync.org/wiki/trunk/installation/checkout_script

Coding

  • read Coding Style Guidelines
  • read Coding Style Guidelines again
  • Build the latest revision of SVN and test latest changes
  • If you're using GCC use CMAKE_BUILD_TYPE=Hacking
  • Get familiar with the devel-branch of OpenSync trunk/hackingGuide
  • Start coding for OpenSync in the trunk/hackingGuide
  • 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
    or without committing results to the dashboard and running a specific testcase (here "format_env_plugin") with error details 
    /usr/bin/ctest --force-new-ctest-process  -R "format_env_plugin" -V
    • 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 releases/0.2x/docOutdateds/0.2x/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 osynctool --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)