Component Builders Guide Sans Bocca

1. Make sure the build for the candidate component builds with the latest CCA Tools "Sumo" tarball.
2. Support at least the --with-ccafe-config switch for the top-level configure.in (and don't forget to run autoconf) in your build to identify where CCA Tools are installed.
3. If your component depends on other libraries that must be built separately, include configure switches sufficient to specify where and how to access those. Though it might be an option, do not assume that the external libraries are installed in canonical places, it may be that the libraries have to be built special for your component.
4. Make sure that your component installs per the standard, identical to the way Bocca does it.
5. When the above is working package your source in a tarball and identify the version with the customary <Major>.<Minor>.<Patch> versioning scheme.
6. Place the tarball in /home/httpd/download/toolkit-components directory on www.cca-forum.org assuming you have an account on the CCA machine and let Rob Armstrong know by email. Otherwise just send the tarball to Rob Armstrong directly.

Suggested Autoconf macros for these options can be lifted from any bocca-generated package. To facilitate packaging of complete tool sets, each package needs to support at least one build option:

and optionally:

i.e.version = %d.%d.%d	In the above scheme, version information can be appended to component name at the developers option. For example: "$COMPONENT_NAME-$version" looks like "libga-3.2.6"
i.e. lang = one of c, cxx, f77, f77_31, f90	For example: "lib$PORT_NAME-lang.so" looks like "libIntegratorPort-f90.so"

Other suggestions:

Whenever possible, apply the following practices to help others easily find the bits they want within your public interface.

• Provide a $PROJECT-config script installed in $prefix/bin to query your installed project's configured locations (libdir, datadir, etc), version, etc.
• One sidl class or interface per SIDL file, with the full sidl name used and .sidl appended. E.g. mypackage.ports.MeshPort.sidl
• If one-per-file is deemed inconvenient, then one-file-per-project (myproject.sidl) or one-file-per-package (mypackage.ports.sidl, mypackage.sidl) are the recommended alternatives.
• One component-per-library is the recommended packaging, however this may be impractical under some circumstances, e.g. where several components wrap a single legacy library which is not itself available as a shared object (.so) library.

gnu standards.
Bocca Reference And Guide