Package directory ----------------- First of all, create a directory under the +package+ directory for your software, for example +libfoo+. Some packages have been grouped by topic in a sub-directory: +multimedia+, +java+, +x11r7+, and +games+. If your package fits in one of these categories, then create your package directory in these. +Config.in+ file ~~~~~~~~~~~~~~~~ Then, create a file named +Config.in+. This file will contain the option descriptions related to our +libfoo+ software that will be used and displayed in the configuration tool. It should basically contain : --------------------------- config BR2_PACKAGE_LIBFOO bool "libfoo" help This is a comment that explains what libfoo is. http://foosoftware.org/libfoo/ --------------------------- 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 +package/Config.in+ (or in a category subdirectory if you decided to put your package in one of the existing categories). The files included there are 'sorted alphabetically' per category and are 'NOT' supposed to contain anything but the 'bare' name of the package. -------------------------- source "package/libfoo/Config.in" -------------------------- The +.mk+ file ~~~~~~~~~~~~~~ Finally, here's the hardest part. Create a file named +libfoo.mk+. It describes how the package should be downloaded, configured, built, 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 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 infrastructure must be used for all packages that do not use the autotools as their build system. In the future, other specialized infrastructures might be written for other build systems. We cover them through in a xref:gentargets-tutorial[tutorial] and a xref:gentargets-reference[reference]. * *Makefiles for autotools-based software* (autoconf, automake, etc.): We provide a dedicated infrastructure for such packages, since autotools is a very common build system. This infrastructure 'must' be used for new packages that rely on the autotools as their build system. We cover them through a xref:autotargets-tutorial[tutorial] and xref:autotargets-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 xref:handwritten-tutorial[tutorial].