Module Guidelines

(Difference between revisions)
Jump to: navigation, search
m (DEPENDS)
m (DEPENDS)
Line 17: Line 17:
 
* 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 (non-optionally) "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 (non-optionally) "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.
+
* Never put logic into this file.  The only things that can exist in this file are function calls to [[depends]] and/or [[optional_depends]].
** 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.
+
* Never put logic into this file.  The only things that can exist in this file are function calls to [[depends]] and/or optional_depends.
+
 
** Putting logic into DEPENDS, while it might seem clever, is a sure way to mess up Lunar's internal dependency handling mechanisms and commands such as [[lvu#leert|lvu leert]].
 
** Putting logic into DEPENDS, while it might seem clever, is a sure way to mess up Lunar's internal dependency handling mechanisms and commands such as [[lvu#leert|lvu leert]].
 +
* If possible, always provide the means 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 20:34, 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

  • Always use a SHA1 checksum instead of a MD5 checksum for SOURCE_VFY values.
    • The SHA1 algorithm has been shown to be less prone to key clashes than the MD5 algorithm.
  • 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 (non-optionally) "libY," you should only add "libX" as a dependency to your module. This is because "libY" will automatically come along with "libX."
  • Never put logic into this file. The only things that can exist in this file are function calls to depends and/or optional_depends.
    • Putting logic into DEPENDS, while it might seem clever, is a sure way to mess up Lunar's internal dependency handling mechanisms and commands such as lvu leert.
  • If possible, always provide the means 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.
  • When removing/renaming a module that had a CONFLICTS file, remember to remove/rename the conflict on all of the other modules this module conflicted with. Don't leave orphaned conflicts.

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.

PRE_REMOVE

POST_REMOVE

Personal tools
Namespaces
Variants
Actions
Wiki Navigation
Project Sites
Toolbox