buildroot/package/pkg-generic.mk, branch 2017.02

package: refactor listing of extractor dependencies

2017-02-15T21:11:11+00:00

Don't special case $(XZCAT) when constructing DL_TOOLS_DEPENDENCIES. The next commit will introduce another extractor that automatically builds when not installed. Introduce EXTRACTOR_DEPENDENCY_PRECHECKED_EXTENSIONS that lists archive extensions for which the extractor is already checked in support/dependencies/check-host-foo.mk. Use this in the newly introduced extractor-dependency to populate DL_TOOLS_DEPENDENCIES. Cc: Thomas De Schampheleire Signed-off-by: Baruch Siach Reviewed-by: Thomas De Schampheleire [Thomas: add missing space after "firstword", as noticed by Thomas DS.] Signed-off-by: Thomas Petazzoni

pkg-generic: run $(PKG)_PRE_RSYNC_HOOKS before checking for the existence of $(SRCDIR)

2016-12-17T15:00:03+00:00

This will allow packages to define their pre-rsync hooks which will be guaranteed to run even if the source is missing. Signed-off-by: Tal Shorer Acked-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

core/pkg-generic: check proper package installation

2016-10-26T20:36:44+00:00

Some packages misbehave, and install files in either $(STAGING_DIR)/$(O) or in $(TARGET_DIR)/$(O) . One common reason for that is that pkgconf now prepends the sysroot path to all the paths it returns. Other reasons vary, but are mostly due to poorly writen generic-packages. And a new step hooks to check that no file gets installed in either location, called after the install-target and install-staging steps. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Romain Naour Signed-off-by: Thomas Petazzoni

core/graph-depends: add option to graph reverse dependencies

2016-10-25T20:59:05+00:00

Now that we can dump the reverse dependencies of a package, add the ability to graph those. It does not make sense to do a full reverse graph, as it would be semantically equivalent to the direct graph. So we only provide a per-package reverse graph. Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

pkg-infra: allow dumping reverse dependencies of a package

2016-10-25T20:51:54+00:00

Finding the packages that select another one in a specific configuration is not very trivial: - when optional, the dependency is not expressed in Kconfig - looking at the .mk files is not very nice. Introduce a way to dump reverse dependencies of packages, i.e. the list of packages that directly depend on that package. Like for direct dependencies, we limit the list to the first-order reverse dependencies. Document it in the main help; use the opportunity to also document foo-show-depends. Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

core: add support for multiple br2-external trees

2016-10-16T11:01:02+00:00

Currently, we only support at most one br2-external tree. Being able to use more than one br2-external tree can be very useful. A use-case would be for having a br2-external to contain the basic packages, basic board defconfigs and board files, provided by one team responsible for the "board-bringup", while other teams consume that br2-external as a base, and complements it each with their own set of packages, defconfigs and extra board files. Another use-case would be for third-parties to provide their own Buildroot packaging in a br2-external tree, along-side the archives for their stuff. Finally, another use-case is to be able to add FLOSS packages in a br2-external tree, and proprietary packages in another. This allows to not touch the Buildroot tree at all, and still be able to get in compliance by providing only that br2-external tree(s) that contains FLOSS packages, leaving aside the br2-external tree(s) with the proprietary bits. What we do is to treat BR2_EXTERNAL as a colon-separated (space- separated also work, and we use that internally) list of paths, on which we iterate to construct: - the list of all br2-external names, BR2_EXTERNAL_NAMES, - the per-br2-external tree BR2_EXTERNAL_$(NAME) variables, which point each to the actual location of the corresponding tree, - the list of paths to all the external.mk files, BR2_EXTERNAL_MKS, - the space-separated list of absolute paths to the external trees, BR2_EXTERNAL_DIRS. Once we have all those variables, we replace references to BR2_EXTERNAL with either one of those. This cascades into how we display the list of defconfigs, so that it is easy to see what br2-external tree provides what defconfigs. As suggested by Arnout, tweak the comment from "User-provided configs" to "External configs", on the assumption that some br2-external trees could be provided by vendors, so not necessarily user-provided. Ditto the menu in Kconfig, changed from "User-provided options" to "External options". Now, when more than one br2-external tree is used, each gets its own sub-menu in the "User-provided options" menu. The sub-menu is labelled with that br2-external tree's name and the sub-menu's first item is a comment with the path to that br2-external tree. If there's only one br2-external tree, then there is no sub-menu; there is a single comment that contains the name and path to the br2-external tree. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Romain Naour Cc: Julien CORJON Signed-off-by: Peter Korsgaard

core: introduce per br2-external NAME

2016-10-16T11:01:02+00:00

This unique NAME is used to construct a per br2-external tree variable, BR2_EXTERNAL_$(NAME)_PATH, which contains the path to the br2-external tree. This variable is available both from Kconfig (set in the Kconfig snippet) and from the .mk files. Also, display the NAME and its path as a comment in the menuconfig. This will ultimately allow us to support multiple br2-external trees at once, with that NAME (and thus BR2_EXTERNAL_$(NAME)) uniquely defining which br2-external tree is being used. The obvious outcome is that BR2_EXTERNAL should now no longer be used to refer to the files in the br2-external tree; that location is now known from the BR2_EXTERNAL_$(NAME)_PATH variable instead. This means we no longer need to expose, and must stop from from exposing BR2_EXTERNAL as a Kconfig variable. Finally, this also fixes a latent bug in the pkg-generic infra, where we would so far always refer to BR2_EXTERNAL (even if not set) to filter the names of packages (to decide whether they are a bootloader, a toolchain or a simple package). Note: since the variables in the Makefile and in Kconfig are named the same, the one we computed early on in the Makefile will be overridden by the one in .config when we have it. Thus, even though they are set to the same raw value, the one from .config is quoted and, being included later in the Makefile, will take precedence, so we just re-include the generated Makefile fragment a third time before includeing the br2-external's Makefiles. That's unfortunate, but there is no easy way around that as we do want the two variables to be named the same in Makefile and Kconfig (and we can't ask the user to un-quote that variable himself either), hence this little dirty triple-inclusion trick. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Romain Naour Signed-off-by: Peter Korsgaard

core/legal-info: save empty string when no license file

2016-10-15T11:15:15+00:00

This is stored in the manifest file; it is perfectly possible to have empty fields in there. Signed-off-by: "Yann E. MORIN" Cc: Luca Ceresoli Cc: Thomas Petazzoni Reviewed-by: Luca Ceresoli Signed-off-by: Thomas Petazzoni

core/legal-info: don't generate big file with all license texts

2016-10-15T10:52:42+00:00

By aggregating all the license files into a single big text-only file means we have no way to use license files that are binary blobs (e.g. pdf, rtf...). Just do not generate that big file; if the user still wants it, it is very easy to create it afterwards. Reported-by: Thomas Petazzoni Signed-off-by: "Yann E. MORIN" Cc: Luca Ceresoli Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

core/pkg-generic: allow packages to declare target-finalize hooks

2016-07-05T13:48:48+00:00

Currently, packages using target finalize hooks must remember that they need to register their hook in TARGET_FINALIZE_HOOKS conditionally (otherwise their hook will be triggered even if the package is disabled). In order to avoid this potential mistake, this commit introduces a per-package target-finalize hook variable, in which packages can register their target-finalize hooks, with the guarantee that they will only be triggered if the package is enabled. Signed-off-by: "Yann E. MORIN" Reviewed-by: Romain Naour [Thomas: rework commit log.] Signed-off-by: Thomas Petazzoni