diff options
Diffstat (limited to 'docs/manual/adding-packages-directory.txt')
| -rw-r--r-- | docs/manual/adding-packages-directory.txt | 70 |
1 files changed, 64 insertions, 6 deletions
diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt index 058ebad1c..0852b045f 100644 --- a/docs/manual/adding-packages-directory.txt +++ b/docs/manual/adding-packages-directory.txt @@ -24,10 +24,16 @@ config BR2_PACKAGE_LIBFOO http://foosoftware.org/libfoo/ --------------------------- -Of course, you can add other options to configure particular things in -your software. You can look at examples in other packages. The syntax -of the +Config.in+ file is the same as the one for the kernel Kconfig -file. The documentation for this syntax is available at +The +bool+ line, +help+ line and other meta-informations about the +configuration option must be indented with one tab. The help text +itself should be indented with one tab and two spaces, and it must +mention the upstream URL of the project. + +Of course, you can add other sub-options into a +if +BR2_PACKAGE_LIBFOO...endif+ statement to configure particular things +in your software. You can look at examples in other packages. The +syntax of the +Config.in+ file is the same as the one for the kernel +Kconfig file. The documentation for this syntax is available at http://lxr.free-electrons.com/source/Documentation/kbuild/kconfig-language.txt[] Finally you have to add your new +libfoo/Config.in+ to @@ -40,6 +46,51 @@ supposed to contain anything but the 'bare' name of the package. source "package/libfoo/Config.in" -------------------------- +The +Config.in+ file of your package must also ensure that +dependencies are enabled. Typically, Buildroot uses the following +rules: + +* Use a +select+ type of dependency for dependencies on + libraries. These dependencies are generally not obvious and it + therefore make sense to have the kconfig system ensure that the + dependencies are selected. For example, the _libgtk2_ package uses + +select BR2_PACKAGE_LIBGLIB2+ to make sure this library is also + enabled. + +* Use a +depends on+ type of dependency when the user really needs to + be aware of the dependency. Typically, Buildroot uses this type of + dependency for dependencies on toolchain options (large file + support, RPC support, IPV6 support), or for dependencies on "big" + things, such as the X.org system. In some cases, especially + dependency on toolchain options, it is recommended to add a + +comment+ displayed when the option is not enabled, so that the user + knows why the package is not available. + +An example illustrates both the usage of +select+ and +depends on+. + +-------------------------- +config BR2_PACKAGE_ACL + bool "acl" + select BR2_PACKAGE_ATTR + depends on BR2_LARGEFILE + help + POSIX Access Control Lists, which are used to define more + fine-grained discretionary access rights for files and + directories. + This package also provides libacl. + + http://savannah.nongnu.org/projects/acl + +comment "acl requires a toolchain with LARGEFILE support" + depends on !BR2_LARGEFILE +-------------------------- + + +Note that such dependencies will make sure that the dependency option +is also enabled, but not necessarily built before your package. To do +so, the dependency also needs to be expressed in the +.mk+ file of the +package. + The +.mk+ file ~~~~~~~~~~~~~~ @@ -50,8 +101,8 @@ installed, etc. Depending on the package type, the +.mk+ file must be written in a different way, using different infrastructures: -* *Makefiles for generic packages* (not using autotools): These are - based on an infrastructure similar to the one used for +* *Makefiles for generic packages* (not using autotools or CMake): + These are based on an infrastructure similar to the one used for autotools-based packages, but requires a little more work from the developer. They specify what should be done for the configuration, compilation, installation and cleanup of the package. This @@ -68,6 +119,13 @@ different way, using different infrastructures: system. We cover them through a xref:autotargets-tutorial[tutorial] and xref:autotargets-reference[reference]. +* *Makefiles for cmake-based software*: We provide a dedicated + infrastructure for such packages, as CMake is a more and more + commonly used build system and has a standardized behaviour. This + infrastructure 'must' be used for new packages that rely on + CMake. We cover them through a xref:cmaketargets-tutorial[tutorial] + and xref:cmaketargets-reference[reference]. + * *Hand-written Makefiles:* These are currently obsolete, and no new manual Makefiles should be added. However, since there are still many of them in the tree, we keep them documented in a |