Documentation Team/Obsolete/Services Binary Services HOWTO

Work flow for services that require compilation stage:

• create local initial service.info by invoking 0sugar init, tweak newly created service/service.info file
• provide relevant value for build-command field in service.info file
• if you want to support binaries for different dependencies environments, add additional sections to service.info file with requires fields that describe dependencies versions of particular environment
• increase/change version field in service.info file
• 0sugar dist to add sources tarball to dist/ and change local feed correspondingly
• on every platform, you are trying to support binaries for, run 0sugar dist_bin to build, and add to local field, binaries for this particular platform
• if you added additional sections to service.info, run 0sugar dist_bin <section-name> in every environment, services.info has additional sections for
• 0sugar push stable to rsync changed files from dist/ to the server
  see #Release workflows for other release scenarios

Support several ABIs of service dependencies

File service.info could contain other sections for various binary implementations. These sections are intended to describe particular dependencies environment and should contain only:

• requires that overwrite Service's section requires

For example if service developer is going to add binary implementations for f9/f11, and the same service dependency in these distributions has different ABIs, activity developer has to build two additional binaries, for f9 and f11. In that case developer creates two sections F9 and F11, put exact dependency versions(to separate particular section from others) and invoke 0sugar dist_bin <section-name> in proper f9/f11 environment.

Development tools support

Useful addons to popular development tools. These are optional features that simplify service development process.

Autotools

Add service.m4 macros file to your project. It provides:

• SERVICE_INIT macro to initialize services support, use it after other (AC|AM)_INIT macros like in [1]
  It takes optional string to define prefix value for DIST_ variables, in most cases it should be just sugar
  Macro exports follows variables:
  • SERVICE_NAME, name of service in service.info file
  • SERVICE_VERSION, version of service in service.info file
  • SERVICE_REVISION, revision number from dist/revision file
  • DIST_NAME, combines prefix macro argument with SERVICE_NAME to use it as a distribution name(see example below)
  • DIST_VERSION, combines SERVICE_VERSION and SERVICE_REVISION to use it as a distribution version(see example below)
  • SERVICE_SUMMARY, summary from service.info file
  • SERVICE_EXTRA_DIST, extra files to include to sources tarball
  • SERVICE_DISTCLEANFILES, auto generated files to cleanup
  • macro also changes PACKAGE and VERSION variables with values from proper DIST_, so it rewrites AC_INIT arguments(you have to use fake values for AC_INIT macro)
  • if [Library] section exists in service.info file, macro will
    • check if SERVICE_VERSION is a plain number
    • export SERVICE_AGE, age from [Library] section
    • export SERVICE_LIBRARY_VERSION which is libtool's -version-info parameter
    • if service.pc.in presents in root directory, rename it to DIST_NAME.pc.in

• SERVICE_ECHO convenient macro to print various variables

These macros could be used like in Toolkit service.