Module Guidelines
(Difference between revisions)
m (→DEPENDS: make this a bit clearer as to what it means) |
m (→DEPENDS) |
||
Line 14: | Line 14: | ||
== DEPENDS == | == DEPENDS == | ||
− | * Only list unique dependencies. | + | *Only list unique dependencies. |
**That means that if the module you are building requires both "libX" and "libY" to properly compile/run but "libX" itself already requires "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX." | **That means that if the module you are building requires both "libX" and "libY" to properly compile/run but "libX" itself already requires "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX." | ||
+ | *If possible always provide a way to disable support for an optional dependency, even if that optional module is installed. | ||
+ | **That means if the application's ./configure script allows for a --disable-my-optional-depends you should include that switch when building your [[optional_depends]] line. This allows you to not-build in support for certain features, even if your computer has the necessary applications/libraries installed to support that feature. Choice is good. | ||
== CONFLICTS == | == CONFLICTS == |
Revision as of 19:54, 28 August 2006
Contents |
Generic
These guidelines apply to all of a module's files.
- Never use tabs. Use spaces instead.
- Use 72 columns as a maximum width whenever possible (but always in the long description in the DETAILS file!).
- Respect the MAINTAINER value. Don't modify maintained modules unless you first consult the listed maintainer.
DETAILS
- Use sha1: instead of md5: for SOURCE_VFY values.
- Don't insert your eMail address into the MAINTAINER field unless you are a Lunar developer.
- Prefer tar.bz2 over tar.gz tarballs (as it saves space/traffic) and prefer tar.gz over zip (or rar) packages.
DEPENDS
- Only list unique dependencies.
- That means that if the module you are building requires both "libX" and "libY" to properly compile/run but "libX" itself already requires "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX."
- If possible always provide a way to disable support for an optional dependency, even if that optional module is installed.
- That means if the application's ./configure script allows for a --disable-my-optional-depends you should include that switch when building your optional_depends line. This allows you to not-build in support for certain features, even if your computer has the necessary applications/libraries installed to support that feature. Choice is good.
CONFLICTS
- Remember to add a CONFLICTS to both modules that conflict with each other.
CONFIGURE
PRE_BUILD
BUILD
- Don't install files after calling devoke_installwatch.
POST_BUILD
- Don't install any files into the system.
POST_INSTALL
- Don't install any files into the system.