Difference between revisions of "Autobuild/Package Layout"

Latest revision as of 10:56, 19 March 2015

Autobuild

Autobuild does not place much in the way of restrictions on how a package is bundled into an archive. The autobuild package command will simply create an archive from the build directory gathering all the files which match manifest entries. When that package is installed using autobuild install, it is just expanded into the packages subdirectory of the build directory. That said, there is a recommended layout of various build products which has (mostly) been followed by Linden apps. On this page we give the details of that recommended layout.

Package layout

The basic layout for a typical package archive is:

bin
include
- include/<packagename>
lib
- lib/debug
- lib/relwithdebinfo
- lib/release
LICENSES

binaries

Package executables in the bin directory of the archive.

headers

Package header files in the include directory of the archive typically in a subdirectory named after the package. For example one might include the header foo.h" for the foo package in include/foo/foo.h.

libraries

Package static and shared libraries in the lib directory in a subdirectory which matches the build configuration (all lower case). This is especially important for packages built for windows where debug and release libraries are binary incompatible. As an example, if the foo package produces a library foo.lib, the version built with debugging enabled should be bundled in lib/debug whereas the optimized version should be bundled in lib/release.

License files

Include a copy of the package's license in the LICENSES directory. By convention, license files are named packagename.txt.

Gotchas

Some existing packages have their libraries located directly under lib, some have them under lib/{debug,relwithdebinfo,release}
Python packages are not fully supported, as we have not determined how to cleanly organize python module directories for compatibility with multiple python versions

@@ Line 1: / Line 1: @@
-The autobuild tool does not place much in the way of restrictions on how a package is bundled into an archive.  The <nowiki>autobuild package</nowiki> command will simply create an archive from the build directory gathering all the files which match manifest entries.  When that package is installed using <nowiki>autobuild install</nowiki>, it is just expanded into the ''packages'' subdirectory of the build directory.  That said, there is a recommended layout of various build products which has (mostly) been followed by Linden apps.  On this page we give the details of that recommended layout.
+{{Autobuild Nav}}
+{|
+|-
+|width=180| __TOC__
+|valign=top| Autobuild does not place much in the way of restrictions on how a package is bundled into an archive.  The <code>autobuild package</code> command will simply create an archive from the build directory gathering all the files which match manifest entries.  When that package is installed using <code>autobuild install</code>, it is just expanded into the ''packages'' subdirectory of the build directory.  That said, there is a recommended layout of various build products which has (mostly) been followed by Linden apps.  On this page we give the details of that recommended layout.
+|}
-=== Pakage layout ===
+=== Package layout ===
-The following list gives the basic expected layout for the typical kinds of build product that may end up in a package archive:
+The basic layout for a typical package archive is:
 *bin
 *include
@@ Line 14: / Line 19: @@
 ==== binaries ====
-Executables should be packaged in the ''bin'' directory  of the archive.
+Package executables in the ''bin'' directory of the archive.
 ==== headers ====
-Header files should be packaged in the ''include'' directory of the archive typically in a subdirectory named after the package.  For example one might include the header ''foo.h" for the ''foo'' package in ''include/foo/foo.h''.
+Package  header files in the ''include'' directory of the archive typically in a subdirectory named after the package.  For example one might include the header ''foo.h" for the ''foo'' package in ''include/foo/foo.h''.
 ==== libraries ====
-Static and shared libraries should be packaged in the ''lib'' directory in a subdirectory which matches the build configuration (all lower case).  This is especially important for packages built for windows where debug and release libraries are binary incompatible.  As an example, if the ''foo'' package produces a library ''foo.lib'', the version built with debugging enabled should be bundled in ''lib/debug'' whereas the optimized version should be bundled in ''lib/release''.
+Package static and shared libraries in the ''lib'' directory in a subdirectory which matches the build configuration (all lower case).  This is especially important for packages built for windows where debug and release libraries are binary incompatible.  As an example, if the ''foo'' package produces a library ''foo.lib'', the version built with debugging enabled should be bundled in ''lib/debug'' whereas the optimized version should be bundled in ''lib/release''.
 ==== License files ====
-A copy of the package's license should be bundled under the ''LICENSES'' directory.  By convention these files have been named ''<nowiki><packagename>.txt</nowiki>''.
+Include a copy of the package's license in the ''LICENSES'' directory.  By convention, license files are named ''<code>packagename''.txt</code>.
 === Gotchas ===
-# some existing packages have their libraries located directly under lib, some have them under lib/{debug,relwithdebinfo,release}
+*Some existing packages have their libraries located directly under lib, some have them under lib/{debug,relwithdebinfo,release}
-# python pacakges are not fully supported, as we have not determined how to cleanly organize python module directories for compatibility with multiple python versions
+*Python packages are not fully supported, as we have not determined how to cleanly organize python module directories for compatibility with multiple python versions
-# this is not compatible with the legacy package layout used in the indra codebase for non autobuild enabled builds. Packages for these builds need to be converted to the legacy layout to be used with install.py for now. UPDATE: {{User|Brad_Linden}} has gotten [[Autobuild/Teamcity|TeamCity]] to do this for us by using a BuildParam value to configure this (build_legacy_package can be set to true).
 [[Category:Autobuild]] [[Category:Open Source Portal]]