Difference between revisions of "Bering-uClibc 4.x - Developer Guide - Policies and Guidelines"

From bering-uClibc
Jump to: navigation, search
(Changed navigation links for new Adding a Kernel Architecture Variant page)
(Added new guideline on where to locate files like .source based on Erich Titl email to leaf-devel 2011-09-14)
Line 9: Line 9:
  
  
The following general Policies and Guidelines should be adopted (if possible / practical) when developing for Bering-uClibc 4.x:
+
The following general Policies and Guidelines should be adopted (if possible / practical) when developing for [[Bering-uClibc 4.x]]:
 
# Upload the upstream package source file to the LEAF source code management system and reference it from there within <tt>buildtool.cfg</tt>.
 
# Upload the upstream package source file to the LEAF source code management system and reference it from there within <tt>buildtool.cfg</tt>.
 
#* This provides a "local" copy in case the upstream distribution location changes or goes away.
 
#* This provides a "local" copy in case the upstream distribution location changes or goes away.
#* This provides an input to the process which creates a downloadable snapshot of all of the source code used for a Bering-uClibc 4.x distribution, which is required to comply with SourceForge terms and conditions. TODO: Add reference to those Ts&Cs.
+
#* This provides an input to the process which creates a downloadable snapshot of all of the source code used for a [[Bering-uClibc 4.x]] distribution, which is required to comply with SourceForge terms and conditions. TODO: Add reference to those Ts&Cs.
 
# Store the upstream package source file in unmodified form.
 
# Store the upstream package source file in unmodified form.
 
#* Do not change the filename. Retain the original compression scheme (preferably <tt>.tar.gz</tt> but alternatively <tt>.tar.bz2</tt> if that is all that is provided).
 
#* Do not change the filename. Retain the original compression scheme (preferably <tt>.tar.gz</tt> but alternatively <tt>.tar.bz2</tt> if that is all that is provided).
Line 18: Line 18:
 
# When adding an extra kernel module to the <tt>kmodules</tt> source package, check whether there is any accompanying firmware (in <tt>/lib/firmware/</tt>). If there is, also specify that in the <tt>kmodules</tt> <tt>buildtool.cfg</tt>.
 
# When adding an extra kernel module to the <tt>kmodules</tt> source package, check whether there is any accompanying firmware (in <tt>/lib/firmware/</tt>). If there is, also specify that in the <tt>kmodules</tt> <tt>buildtool.cfg</tt>.
 
#* Refer to the <tt>e100</tt> entry as an example.
 
#* Refer to the <tt>e100</tt> entry as an example.
# Do not place kernel Modules into Package <tt>.lrp</tt> files. Place modules only in <tt>moddb.lrp</tt> and <tt>modules.tgz</tt>.
+
# Do not place kernel Modules into Package <tt>.lrp</tt> files. Place Modules only in <tt>moddb.lrp</tt> and <tt>modules.tgz</tt>.
 +
# Within <code class=filename>buildtool.mk</code>, place "flag" files like <code class=filename>.source</code> directly alongside the source <code class=filename>.tar.gz</code> archive, not within the un-packed directory structure.
  
  

Revision as of 13:10, 25 September 2011

Policies and Guidelines
Prev Bering-uClibc 4.x - Developer Guide Next


The following general Policies and Guidelines should be adopted (if possible / practical) when developing for Bering-uClibc 4.x:

  1. Upload the upstream package source file to the LEAF source code management system and reference it from there within buildtool.cfg.
    • This provides a "local" copy in case the upstream distribution location changes or goes away.
    • This provides an input to the process which creates a downloadable snapshot of all of the source code used for a Bering-uClibc 4.x distribution, which is required to comply with SourceForge terms and conditions. TODO: Add reference to those Ts&Cs.
  2. Store the upstream package source file in unmodified form.
    • Do not change the filename. Retain the original compression scheme (preferably .tar.gz but alternatively .tar.bz2 if that is all that is provided).
    • Make changes by "patching" the unpacked files as part of the build process defined in buildtool.mk.
  3. When adding an extra kernel module to the kmodules source package, check whether there is any accompanying firmware (in /lib/firmware/). If there is, also specify that in the kmodules buildtool.cfg.
    • Refer to the e100 entry as an example.
  4. Do not place kernel Modules into Package .lrp files. Place Modules only in moddb.lrp and modules.tgz.
  5. Within buildtool.mk, place "flag" files like .source directly alongside the source .tar.gz archive, not within the un-packed directory structure.



Prev Up Next