Writing Project Services
Project services are services that are checked into the CVS module for the project, rather than being maintained as Wigwam packages.
They don't have explicit version numbers, because they are in the project's CVS module. Hence tagging the project uniquely identifies a "version" of the service.
They are useful for providing services that aren't needed by other projects, so should not be in the package archive.
Project services are just like package services, except:
They are not in ext/, they are simply in $PLAYPEN_ROOT/services/SERVICE_NAME.
They never have a version number, and wherever $service_name-$service_version is used, it is replaced with just $service_name.
They are managed by the project's CVS module -- not the packaging system.
Here is what you must do to define a new project service:
Edit or create etc/project-services. It must contain a line which is just the name of the service.
Make sure binaries exist for the service. If you are going to use packaged binaries, just packagectl install them. If you are going to implement your own daemons, the code should be in src; it should be possible to build and install that code as described in the Section called Building and Installing Binaries in a Project.
Create a directory services/$service_name. Make a config there that describes how to run the service; the variables are exactly the same as for packaged services.
At this point, you should be able to use servicectl to start and stop the new project service.
Building and Installing Binaries in a Project
This section applies to writing code in a project in order to run a project service.
This implies that you are writing code that you don't intend to reuse in another project. Please consider making your code general enough that it can be placed into a package to be used for many other projects.
Like packages, the project source code is installed in two phases.
If you use automake, all the building and installing is completely standardized, and Wigwam will handle it without the project-build and project-install scripts.
 | If you use automake and autoconf, be sure that your configure script, Makefile.ins, and Makefiles will be regenerated automatically when their corresponding input files (configure.in, Makefile.am, Makefile.in) change. Specifically, you probably do not want to use the AM_MAINTAINER_MODE macro, because it disables those rules by default. |
Alternately, you may write a simple Makefile where
make PREFIX=$prefix |
make PREFIX=$prefix install |
If you do not want to use automake, or if your project is very unusual, you may prefer to write custom build and install scripts.
- build
If a file src/project-build exists, then that will be run to build the project. This process should check availability of the libraries and check that the code compiles, but should not touch any files outside of src.
- install
If a file src/project-install exists, then that will be run to install the project. That means copying its libraries into lib, its executables into bin, and so on.
- configure
Automake and other source code configuration tools have a separate phase for finding out what features are available on the local platform. If you are not using automake, a src/project-configure script will be tried. If that does not exist, we assume that this project has no source code configuration phase.
- clean
Clean up compiled object files, libraries and executables. If you are not using automake or make, a src/project-clean script will be tried. If that does not exist, you cannot clean this project---you should fix that.