Table of Contents
It is a fact that Buildtool is complex. Making a package which conforms to all its features is a hard task, specially if you are a new developer who is starting to use it. Luckily for you, the bt_lint module verifies your package against common standards and warns you about wrong things.
Some of the checks included now will tell you to make your package compliant with the Buildtool standards; these checks are weak, to avoid forcing you to use something you may not like. In a future, support for other standards (like GNU) may be added.
To verify your package, simply run the buildtool lint command from the top level directory of your source package. It will run some tests and, at the end, show a summary about check results. Checks can result in one of the following three states:
Your package misses something required for proper Buildtool operation. These will not (usually) refer to missing files.
Your package is ok, but could be better. Most of the warnings refer to some things you may do to make your package more standards compliant. These checks usually refer to missing files or variables not used. You can omit them, as they are only suggestions.
Your package is perfect, according to your Buildtool version. It should keep this status even if you update Buildtool to another version inside the same branch (major number). See Section 1.3, “Versioning” for more details.
The Buildtool standards aim to create a set of guidelines to keep all buildtoolized packages somewhat consistant. A user should be able to gather information about a package quickly if he is aware of these standards. The following subsections document all their details.
The top directory of a package is reserved to hold build and package related documentation. You can place as many documents as you want using any name you can think (tipically in upper case). Even though, you should maintain some consistency with other packages developed by other people. The following list contains a list of recommended documents; you may not want to include them or you may prefer other names.
A list of the most important changes between different versions. This should not be an exhaustive list of very specific details, as this is maintained by configuration management systems, like CVS, if you are using any of them.
A copy of the license terms that affect your package.
Authors, contributors, or any other kind of people related to your package. This file overrides the AUTHORS and the THANKS files, present in most packages. Ask yourself: why keep two different files that contain the same kind of information?
Generic documentation about your package that is of interest to end users building and/or installing it.
Automatically provided by Buildtool, this file tells the user that the package is buildtoolized and how to get more information. You must not modify this document; it should remain the same across packages that include it.