summaryrefslogtreecommitdiffstats
path: root/support
Commit message (Collapse)AuthorAgeFilesLines
...
* core/graph-depends: add option to graph reverse dependenciesYann E. MORIN2016-10-251-2/+16
| | | | | | | | | | | | | | 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" <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* scripts/get-developers: correct type of patches argumentRahul Bedarkar2016-10-252-15/+14
| | | | | | | | | | | | | | | Current type for 'patches' argument is str. It supposed to only contain names of files. If we specify FileType as type, then we don't need to open file ourself and it allows script to read patch from standard input as well. e.g. $ git show -1 | ./support/scripts/get-developers - Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchainfile.cmake: fix description of CMAKE_Fortran_FLAGS_{DEBUG,RELEASE}Thomas Petazzoni2016-10-221-2/+2
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toochainfile.cmake: rework the way Buildroot sets flagsSamuel Martin2016-10-221-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the build configuration, Buildroot defines and set some compiler and linker flags that should be passed to any packages build-system. For package using the cmake-package infrastructure, this is achieved via the toolchainfile.cmake. This change simplifies the way the toolchainfile.cmake file handles these flags: it now just sets them, without any attempt to extend them with those Buildroot defined. This change still allows overriding these flags from the configure command line. So, now, when a CMake-based package needs to extend them, they should be fully set from the package *.mk file. This behavior is consistent with what is done for others package infrastructures. This change should not pull any regression WRT the bug #7280 [1]. However, now, when someone uses the toolchainfile.cmake file outside of Buildroot, he/she must overload all compiler/linker flags (including the ones Buildroot sets since they no longer get automatically added). [1] https://bugs.busybox.net/show_bug.cgi?id=7280 Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchainfile.cmake: set per-config appended {C, CXX}FLAGSSamuel Martin2016-10-221-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a build type is set, CMake does append some flags that can override those set by Buildroot due to the gcc option parser (in which the last argument controling an option wins). Hereafter is a summary of the optimization and debug flags set by Buildroot and appended by CMake. * Flags set by Buildroot depending on the configuration: BR2_ENABLE_DEBUG | Optim. level | Buildroot {C,CXX}FLAGS =================+=====================+======================= y | BR2_OPTIMIZE_S | -Os -gx y | BR2_OPTIMIZE_G | -Og -gx y | BR2_OPTIMIZE_{0..3} | -On -gx n | BR2_OPTIMIZE_S | -Os n | BR2_OPTIMIZE_G | -Og n | BR2_OPTIMIZE_{0..3} | -On * Default flags appended by CMake depending on the build type: Build type | Flags | Effects on {C,CXX}FLAGS ===============+=================+=========================================== Debug | -g | Force -g, compatible with BR2_ENABLE_DEBUG MinSizeRel | -Os -DNDEBUG | Set -Os, compatible with BR2_OPTIMIZE_S Release | -O3 -DNDEBUG | Set -O3, closest to the others cases, | | though the optimization level is forced. RelWithDebInfo | -O2 -g -DNDEBUG | Force -g and set -O2, not friendly with BR To avoid the CMake flags take precedence over the Buildroot ones, this change sets in toolchainfile.cmake the per-config compiler flags CMake can append depending on the build type Buildroot defined. So, CMake does not mess up with the compilation flags Buildroot sets. It is still possible to override these per-config flags on the cmake command line. Note: If a CMake-based project forces the compiler and/or linker flag definitions (the default ones or the per-config ones - e.g. CMAKE_C_FLAGS/CMAKE_C_FLAGS_{DEBUG,RELEASE}), there is not much Buildroot can do about it. So, the flags will be overwritten anyway in these cases. Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: - adjust comment in toolchainfile.cmake.in, as suggested by Arnout. - also handle CMAKE_Fortran_FLAGS_*, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/pkg-cmake.mk: move CMAKE_BUILD_TYPE definition into toolchainfile.cmakeSamuel Martin2016-10-221-0/+3
| | | | | | | | | | | | | | | | The chosen CMAKE_BUILD_TYPE encodes an option of the Buildroot configuration, so it makes more sense to save it in the toolchainfile.cmake than to pass it during configure. It is still possible to override the build type on the cmake command line. Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: reword description in the CHANGES file.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* get-developers: use --cc instead of --to for developersRahul Bedarkar2016-10-191-1/+1
| | | | | | | | | Output of get-developers script in our manual uses --cc for developers, but actual output of get-developers script uses --to. This patch makes code consistent with documentation, by using --cc for developers. Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core/br2-external: fix link to manual for converting old treesYann E. MORIN2016-10-191-1/+1
| | | | | | | | | | | To be noted: that link will only be valid once we have a released manual. In the meantime, it's accessible on the nightly manual: http://nightly.buildroot.org/#br2-external-converting Reported-by: Benoît Allard <benoit.allard@greenbone.net> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Benoît Allard <benoit.allard@greenbone.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core/br2-external: export paths and descriptionsYann E. MORIN2016-10-191-2/+2
| | | | | | | | | | | | | | | | | | | | | Now that we support multiple br2-external trees, BR2_EXTERNAL is no longer exported in the environment. This means that post-build scripts in a br2-external tree can no longer find their own files (well, they could re-invent the path by stripping their known-relative path, but that'd be ugly, especially since we can very well provide it). Export the path for each br2-external trees as environment variables. Do so for the description as well, as a courtesy. Also, re-order variable definitions to be more logical: first, purely internal variables, then exported variables. Reported-by: Benoît Allard <benoit.allard@greenbone.net> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Benoît Allard <benoit.allard@greenbone.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* support/misc/Vagrantfile: bump to ubuntu 16.04Angelo Compagnucci2016-10-191-3/+6
| | | | | | | | | | | * Updating to ubuntu 16.04 * Fixing dependencies * Fixing locale complaints * Removing unused packages Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core: support description for br2-external treesYann E. MORIN2016-10-161-3/+9
| | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core: allow a br2-external tree to override a defconfigYann E. MORIN2016-10-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is not possible for a br2-external tree to override a defconfig bundled in Buildroot, nor is it possible to override one from a previous br2-external tree in the stack. However, it is interesting that a latter br2-external tree be able to override a defconfig: - the ones bundled in Buildroot are minimalist, and almost always build a toolchain, so a br2-external tree may want to provide a "better" defconfig (better, in the sense "suited for the project"); - similarly for a defconfig from a previous br2-external tree. But we can't do that, as the rules for the defconfigs are generated in the order the br2-external trees are specified, all after the bundled defconfigs. Those rule are patten-matching rules, which means that the first one to match is used, and the following ones are ignored. Add a new utility macro, 'reverse', inspired from GMSL, that does what it says: reverse a list of words. Use that macro to reverse the list of br2-external trees, so that the latters win over the formers, and even over bundled ones. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core: add support for multiple br2-external treesYann E. MORIN2016-10-161-40/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* docs/manual: add appendix to convert old br2-external treesYann E. MORIN2016-10-161-1/+6
| | | | | | | | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> [Peter: slightly reword] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core: introduce per br2-external NAMEYann E. MORIN2016-10-161-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core/br2-external: validate even moreYann E. MORIN2016-10-161-0/+6
| | | | | | | | | | A br2-external tree must provide external.mk and Config.in. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core: offload handling of BR2_EXTERNAL into the scriptYann E. MORIN2016-10-161-8/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we treat the case where we have no br2-external tree (BR2_EXTERNAL is empty) differently from the case where we do have one (BR2_EXTERNAL is not empty). There is now no reason to treat those two cases differently: - the kconfig snippet is always generated appropriately (i.e. it would include the br2-external tree if set, or include nothing otherwise); - we no longer have a dummy br-external tree either. Also, the Makefile code to handle BR2_EXTERNAL is currently quite readable if at least a little bit tricky. However, when we're going to add support for using multiple br2-external trees simultaneously, this code would need to get much, much more complex. To keep the Makefile (rather) simple, offload all of the handling of BR2_EXTERNAL to the recently added br2-external helper script. However, because of Makefiles idiosyncracies, we can't use a rule to generate that Makefile fragment. Instead, we use $(shell ...) to call the helper script, and include the fragment twice: once before the $(shell ...) so we can grab a previously defined BR2_EXTERNAL value, a second time to use the one passed on the command line, if any. Furthermore, we can't error out (e.g. on non-existent br2-external tree) directly from the fragment or we'd get that error on subsequent calls, with no chance to override it even from command line. Instead, we use a variable in which we store the error, set it to empty before the second inclusion, so that only the one newly generated, if any, is taken into account. Since we know the script will always be called from Makefile context first, we know validation will occur in Makefile context first. So we can assume that, if there is an error, it will be detected in Makefile context. Consequently, if the script is called to generate the kconfig fragment, validation has already occured, and there should be no error. So we change the error function to generate Makefile code, so that errors are caught as explained above. Lastly, when the value of BR2_EXTERNAL changes, we want to 'forget' about the previous value of the BR2_EXTERNAL_MK variable, especially in the case where BR2_EXTERNAL is now set to empty, so that we do not try to include it later. That's why we first generate empty version of BR2_EXTERNAL_MK, and then assign it the new value, if any. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core: get rid of our dummy br2-external treeYann E. MORIN2016-10-163-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we generate a kconfig snippet, we can conditionally include the BR2_EXTERNAL's Config.in only when BR2_EXTERNAL is supplied by the user, which means our empty/dummy Config.in is no needed. As for external.mk, we can also include it only when BR2_EXTERNAL is supplied by the user, which means our empty/dummy external.mk is no longer needed. Ditch both of those files, and: - only generate actual content in the Kconfig snippet when we actually do have a BR2_EXTERNAL provided by the user (i.e. BR2_EXTERNAL is not empty); - add a variable that contains the path to the external.mk provided by the user, or empty if none, and include the path set in that variable (make can 'include' nothing without any problem! ;-) ) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* core: do not hard-code inclusion of br2-external in KconfigYann E. MORIN2016-10-161-0/+88
| | | | | | | | | | | | | | | | | | | | | | Move the inclusion of br2-external's Config.in to the generated kconfig snippet. This will ultimately allow us to use more than one br2-external tree. Offload the "User-provided options" menu to the generated Kconfig snippet. We can also move the definition of the Kconfig-version of BR2_EXTERNAL into this snippet. We introduce an extra check that was not present in the previous code, to check that we do have permission on that directory. Prevciously, it was handled as a side effect of not being able to cd into there, but it is cleaner to check it expressly. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* dependencies: check for Math BigInt/BigRat Perl moduleRomain Naour2016-10-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As for MakeMaker Perl module, add a check for Math BigInt/BigRat Perl Core module, which are needed by mpv. Fixes: Waf: Entering directory `output/build/mpv-0.17.0/build' [ 1/198] Compiling version.sh [ 12/198] Processing ebml_types.h: demux/ebml.c demux/demux_mkv.c -> build/ebml_types.h [ 13/198] Compiling demux/ebml.c Can't locate Math/BigRat.pm in @INC (you may need to install the Math::BigRat module) Waf: Entering directory `output/build/mpv-0.17.0/build' [ 1/198] Compiling version.sh [ 2/198] Compiling TOOLS/osxbundle/mpv.app/Contents/Resources/icon.icns [ 3/198] Compiling video/out/x11_icon.bin [ 4/198] Compiling etc/input.conf [ 5/198] Compiling sub/osd_font.otf [ 6/198] Compiling video/out/opengl/nnedi3_weights.bin [ 7/198] Compiling player/lua/defaults.lua [ 8/198] Compiling player/lua/assdraw.lua [ 9/198] Compiling player/lua/options.lua [ 10/198] Compiling player/lua/osc.lua [ 11/198] Compiling player/lua/ytdl_hook.lua [ 12/198] Processing ebml_types.h: demux/ebml.c demux/demux_mkv.c -> build/ebml_types.h [ 13/198] Compiling demux/ebml.c [ 14/198] Compiling DOCS/man/mpv.rst Can't locate Math/BigInt.pm in @INC (you may need to install the Math::BigInt module) Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: François Perrad <francois.perrad@gadz.org> [Thomas et al.: make those perl modules only required when mpv is enabled.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* dependencies: check for MakeMaker Perl moduleRomain Naour2016-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | ExtUtils::MakeMaker is one of the Perl Core modules usually packaged in Perl package for a Debian/Ubuntu based system. For a Fedora based system, each Perl Core modules have their own RPM package. So install only Perl package is not enough. Fixes: >>> host-libxml-parser-perl 2.41 Configuring [...] perl `which perl` Makefile.PL Can't locate ExtUtils/MakeMaker.pm in @INC (you may need to install the ExtUtils::MakeMaker module) Add a new Perl module check in dependency.sh. Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: François Perrad <francois.perrad@gadz.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* support/scripts/get-developers: add new scriptThomas Petazzoni2016-09-212-0/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This script, and its companion library, is more-or-less Buildroot's equivalent to the kernel get_maintainer.pl script: it allows to get the list of developers to whom a set of patches should be sent to. To do so, it first relies on a text file, named DEVELOPERS, at the root of the Buildroot source tree (added in a followup commit) to list the developers and the files they are interested in. The DEVELOPERS file's format is simple: N: Firstname Lastname <email> F: path/to/file F: path/to/another/file This allows to associate developers with the files they are looking after, be they related to a package, a defconfig, a filesystem image, a package infrastructure, the documentation, or anything else. When a directory is given, the tool assumes that the developer handles all files and subdirectories in this directory. For example "package/qt5/" can be used for the developers looking after all the Qt5 packages. Conventional shell patterns can be used, so "package/python-*" can be used for the developers who want to look after all packages matching "python-*". A few files are recognized specially: - .mk files are parsed, and if they contain $(eval $(<something>-package)), the developer is assumed to be looking after the corresponding package. This way, autobuilder failures for this package can be reported directly to this developer. - arch/Config.in.<arch> files are recognized as "the developer is looking after the <arch> architecture". In this case, get-developer parses the arch/Config.in.<arch> to get the list of possible BR2_ARCH values. This way, autobuilder failures for this package can be reported directly to this developer. - pkg/pkg-<infra>.mk are recognized as "the developer is looking after the <infra> package infrastructure. In this case, any patch that adds or touches a .mk file that uses this infrastructure will be sent to this developer. Examples of usage: $ ./support/scripts/get-developers 0001-ffmpeg-fix-bfin-build.patch git send-email--to buildroot@buildroot.org --to "Luca Ceresoli <luca@lucaceresoli.net>" --to "Bernd Kuhls <bernd.kuhls@t-online.de>" $ ./support/scripts/get-developers -p imx-lib Arnout Vandecappelle <arnout@mind.be> Gary Bisson <gary.bisson@boundarydevices.com> $ ./support/scripts/get-developers -a bfin Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* manual: get rid of the lists of packagesYann E. MORIN2016-09-193-4084/+0
| | | | | | | | | | | | | | | | | | | | | | | | | We currently have four lists of packages in the manual: - the non-virtual target packages, - the virtual target packages, - the host packages, - the deprecated features. Those list take more than half of the manual. They do not serve much purpose except to show off. After the recent discussion on the list [0], remove them all. We can now get rid of our biggish and complex generating script (and its companion library kconfiglib). [0] http://lists.busybox.net/pipermail/buildroot/2016-September/171199.html Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core: don't build host-cmake if it is available on the build hostLuca Ceresoli2016-09-172-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently all cmake packages depend on host-cmake. Unfortunately host-cmake takes a long time to configure and build: almost 7 minutes on a dual-core i5 with SSD. The time does not change even with ccache enabled. Indeed, building host-cmake is avoidable if it is already installed on the build host: CMake is supposed to be quite portable, and the only patch in Buildroot for the CMake package seems to only affect target-cmake. Thus we automatically skip building host-cmake and use the one on the system if: - cmake is available on the system and - it is recent enough. First, we leverage the existing infrastructure in support/dependencies/dependencies.mk to find out whether there's a suitable cmake executable on the system. Its path can be passed in the BR2_CMAKE environment variable, otherwise it defaults to "cmake". If it is enabled, found and suitable then we set BR2_CMAKE_HOST_DEPENDENCY to empty; otherwise we set BR2_CMAKE_HOST_DEPENDENCY to 'host-cmake' and override BR2_CMAKE with "$(HOST_DIR)/usr/bin/cmake" to revert to using our own cmake (the old behaviour). Then in pkg-cmake.mk we replace the hard-coded dependency on host-cmake to using the BR2_CMAKE_HOST_DEPENDENCY variable, and we use $(BR2_CMAKE) instead of $(HOST_DIR)/usr/bin/cmake. Unlike what we do for host-tar and host-xzcat, for host-cmake we do not add host-cmake to DEPENDENCIES_HOST_PREREQ. If we did, host-cmake would be a dependency for _any_ package when it's not installed on the host, even when no cmake package is selected. Cmake versions older than 3.0 are affected by the bug described and fixed in Buildroot in ef2c1970e4bf ("cmake: add patch to fix Qt mkspecs detection"). The bug was fixed in upstream CMake in version 3.0 [0]. Amongst all the cmake packages currently in Buildroot, the currently highest version mentioned in cmake_minimum_required() is 3.1 (grantlee and opencv3). Thus we use 3.1 as the lowest required cmake for now, until a package is bumped, or a new package added, with a higher required version. [0] https://cmake.org/gitweb?p=cmake.git;h=e8b8b37ef6fef094940d3384df5a1d421b9fa568 Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Davide Viti <zinosat@tiscali.it> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Tested-by: Romain Naour <romain.naour@gmail.com> [yann.morin.1998@free.fr: - simplify logic in check-host-cmake.mk; - set and use BR2_CMAKE_HOST_DEPENDENCY, drop USE_SYSTEM_CMAKE; - bump to cmake 3.1 for grantlee and opencv; ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Merge branch 'next'Peter Korsgaard2016-09-029-9/+136
|\ | | | | | | | | | | Quite some conflicts, so here goes .. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * core: move pkg-utils.mk to support/Yann E. MORIN2016-08-271-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pkg-utils.mk contains various definitions that are used in the package infrastructures and packages themselves. However, those definitions can be useful in other parts of Buildroot, and are already used in a few places that are not related to the package infrastructure. Also, $(sep) will be needed early in the Makefile when we eventually support multiple br2-external trees. Since this file only contains definitions, we can include it anytime. So, consider that file to no longer be specific to the package infras: - move it to support and rename it, - move a few similar definitions from the main Makefile to that file. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * support/download: Add support to pass options directly to downloadersRomain Perier2016-08-238-9/+25
| | | | | | | | | | | | | | | | | | | | | | This adds support to pass options to the underlying command that is used by downloader. Useful for retrieving data with server-side checking for user login or passwords, use a proxy or use specific options for cloning a repository via git and hg. Signed-off-by: Romain Perier <romain.perier@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | Update for 2016.082016.08Peter Korsgaard2016-09-011-1/+1
| | | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | docs: libtool patches are not handled by legal-info infrastructure.Romain Naour2016-08-191-0/+5
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> [Thomas: slightly reword with Yann's suggestion.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | pkg-cmake.mk: set CMAKE_SYSROOT variable in toolchainfile.cmakeSamuel Martin2016-08-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change enforces the CMAKE_SYSROOT value set in the toolchainfile.cmake. This fix overrides the CMake heuristics used to guess it, and turns off some non-desirable behavior adding "-isystem ..." flags to the compiler command line, misleading the compiler and making the build failed due to some unfound standard headers. Fixes: http://autobuild.buildroot.net/results/f7e/f7e92678e91a6cb15ccf32d4a7d75b39f49d6000/defconfig (and others) Cc: Ben Boeckel <mathstuf@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | size-stats: fix bug when parsing file names with commaThomas Petazzoni2016-08-091-1/+1
|/ | | | | | | | | | | | | | | | | | | The size-stats script fails when the usb_modeswitch_data is enabled, because this package installs files that contain commas in their name. However, the size-stats script also uses comma as a separator for its CSV files, causing a "ValueError: too many values to unpack" in: pkg, fpath = l.split(",") Fix this by splitting only the two fields that need to be split. The bug was reported by Matthias <porto.rio@gmx.net>, who also suggested a fix. Fixes bug #9136. Reported-by: Matthias <porto.rio@gmx.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* support/download/git: Fix compatibility issue with git older than 1.8.4Enrique Ocaña González2016-07-281-1/+1
| | | | | | | | | | | | The "--no-patch" option used by the git downloader appeared on git 1.8.4. Systems with older git versions show an error and fall back to the wget downloader, which isn't suitable for all the cases. Signed-off-by: Enrique Ocaña González <eocanha@igalia.com> Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* support: pkg-stats: add efl package in packages statsRomain Naour2016-07-241-1/+0
| | | | | | | | Since efl update to 1.15 version, the efl package is a "real" Buildroot package. It doesn't contain any subdirectories anymore. Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* scanpypi: include LICENCE in the list of supported license filesYegor Yefremov2016-07-071-1/+2
| | | | | Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* support/apply-patches: re-instate set -eYann E. MORIN2016-07-061-1/+3
| | | | | | | | | | | | | | | | | | | As reported by Sébastien Szymanski [1], the apply-patches script doesn't stop if a tar command can't extract an archive. Use "set -e" to exit immediately if a command return an error. Be sure to ignore any expected error: when we check if a patch to be applied has the same basename as an already applied patch, the grep would fail when no such patch was already applied. We should not fail in this case. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Cc: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Romain Naour <romain.naour@gmail.com> Tested-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Revert "apply-patches: catch unexpected failure"Thomas Petazzoni2016-07-051-3/+0
| | | | | | | | This reverts commit 9cf1ad6cdb37c5be5772121896f4b13ec42c2b0d. This breaks many packages. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* apply-patches: catch unexpected failureRomain Naour2016-07-051-0/+3
| | | | | | | | | | | | | As reported by Sébastien Szymanski [1], the apply-patches script doesn't stop if a tar command can't extract an archive. Use "set -e" to exit immediately if a command return an error. [1] http://patchwork.ozlabs.org/patch/626196 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* scancpan: improve message when bad host perl versionFrancois Perrad2016-07-041-5/+14
| | | | | | | | | | Signed-off-by: Francois Perrad <francois.perrad@gadz.org> [Thomas: - add comment in scancpan about the version dependency, suggested by Yann E. Morin. - add comment in perl.mk about the need to sync any version change with scancpan, also suggested by Yann E. Morin.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* scanpypi: change hash file commentsYegor Yefremov2016-07-041-3/+2
| | | | | | | | | | sha256 checksum will be computed locally either by scanpypi at package creation or by hand by package updates. Define this checksum as 'computed locally' so that one doesn't need to change this comment by package updates. Also put comments for both md5 and sha256 in one line. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* support/download: don't over-remove files from git archivesYann E. MORIN2016-07-041-3/+3
| | | | | | | | | | | | | | | | | When we now manually create git archives, we removed all .git-related files. However, we also exclude empty directories. This means that a directory which only had a .gitignore file is excluded from the archive. Fixes: http://autobuild.buildroot.org/results/2aa/2aa8954311f009988880d27b6e48af91bc74c346/ http://autobuild.buildroot.org/results/b45/b45cceea99b9860ccf1c925eeda498a823b30903/ http://autobuild.buildroot.org/results/5ae/5ae336052fd32057d9631649279e142a81f5651f/ http://autobuild.buildroot.org/results/5fc/5fc3abf4a1aea677f576e16c49253d00720a8bef/ Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* scanpypi: fix help text handlingYegor Yefremov2016-07-041-0/+5
| | | | | | | Make sure a help text is terminated with a full stop. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* pkg-cmake.mk: export the fortran compiler path in the CMake toolchain fileSamuel Martin2016-07-031-0/+4
| | | | | | | | | Since the fortran support is conditional, only enable it when needed. Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Benjamin Kamath <bkamath@spaceflight.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core/pkg-infra: download git submodules if the package wants themYann E. MORIN2016-07-021-3/+4
| | | | | | | | | | | | | | | Add a new package variable that packages can set to specify that they need git submodules. Only accept this option if the download method is git, as we can not get submodules via an http download (via wget). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Aleksandar Simeonov <aleksandar@barix.com> Tested-by: Matt Weber <matt@thewebers.ws> Reviewed-by: Matt Weber <matt@thewebers.ws> Tested-By: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* support/download/git: add support for submodulesYann E. MORIN2016-07-021-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some git repositories may be split into a master repository and submodules. Up until now, we did not have support for submodules, because we were using bare clones, in which it is not possible to update the list of submodules. Now that we are using plain clones with a working copy, we can retrieve the submdoules. Add an option to the git download helper to kick the update of submodules, so that they are only fetched for those packages that require them. Also document the existing -q option at the same time. Submodules have a .git file at their root, which contains the path to the real .git directory of the master repository. Since we remove it, there is no point in keeping those .git files either. Note: this is currently unused, but will be enabled with the follow-up patch that adds the necessary parts in the pkg-generic and pkg-download infrastructures. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: Matt Weber <matt@thewebers.ws> Reviewed-by: Matt Weber <matt@thewebers.ws> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* support/download/git: do not use git archive, handle it manuallyYann E. MORIN2016-07-021-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use git-archive to generate the tarball. This is all handy and dandy, but git-archive does not support submodules. In the follow-up patch, we're going to handle submodules, so we would not be able to use git-archive. Instead, we manually generate the archive: - extract the tree to the requested cset, - get the date of the commit to store in the archive, - store only numeric owners, - store owner and group as 0 (zero, although any arbitrary value would have been fine, as long as it's a constant), - sort the files to store in the archive. We also get rid of the .git directory, because there is no reason to keep it in the context of Buildroot. Some people would love to keep it so as to speed up later downloads when updating a package, but that is not really doable. For example: - use current Buildroot - it would need foo-12345, so do a clone and keep the .git in the generated tarball - update Buildroot - it would need foo-98765 For that second clone, how could we know we would have to first extract foo-12345 ? So, the .git in the archive is pretty much useless for Buildroot. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: Matt Weber <matt@thewebers.ws> Reviewed-by: Matt Weber <matt@thewebers.ws> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* support/download/git: do not use bare clonesYann E. MORIN2016-07-021-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we are using bare clones, so as to minimise the disk usage, most notably for largeish repositories such as the one for the Linux kernel, which can go beyond the 1GiB barrier. However, this precludes updating (and thus using) the submodules, if any, of the repositories, as a working copy is required to use submodules (becaue we need to know the list of submodules, where to find them, where to clone them, what cset to checkout, and all those is dependent upon the checked out cset of the father repository). Switch to using /plain/ clones with a working copy. This means that the extra refs used by some forges (like pull-requests for Github, or changes for gerrit...) are no longer fetched as part of the clone, because git does not offer to do a mirror clone when there is a working copy. Instead, we have to fetch those special refs by hand. Since there is no easy solution to know whether the cset the user asked for is such a special ref or not, we just try to always fetch the cset requested by the user; if this fails, we assume that this is not a special ref (most probably, it is a sha1) and we defer the check to the archive creation, which would fail if the requested cset is missing anyway. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: Matt Weber <matt@thewebers.ws> Reviewed-by: Matt Weber <matt@thewebers.ws> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* scanpypi: rework runtime dependency handlingYegor Yefremov2016-07-011-3/+1
| | | | | | | | | | | | | | In most cases Python's package dependencies found in setup.py are runtime dependencies and hence don't need to be mentioned in *.mk file. Also add '# runtime' tag to select statements in Config.in. __create_mk_requirements() itself is left for future uses (cffi backend handling etc.). Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* legal-info: explicitly state how patches are licensedLuca Ceresoli2016-06-241-1/+2
| | | | | | | | | | Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [yann.morin.1998@free.fr: slightly tweak after Arnout's review] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* core/legal-info: also save patchesYann E. MORIN2016-06-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the legal-info infra only saves the source archive of a package. However, that's not enough as we may apply some patches on packages sources. We do suggest users to also redistribute the Buildroot sources as part of their compliance distribution, so the patches bundled in Buildroot would indeed be included in the compliance distribution. However, that's still not enough, since we may download some patches, or the user may use a global patch directory. Patches in there might not end up in the compliance distribution, and there are risks of non-conformity. So, always include patches alongside the source archive. To ensure reproducibility, we also generate a series file, so patches can be re-applied in the correct order. We get the list of patches to include from the list of patches that were applied by the package infrastructure (via the apply-patches support script). So, we need to get packages properly extracted and patched before we can save their legal-info, not just in the case they define _LICENSE_FILES. Update the legal-info header accordingly. Note: this means that, when a package is not patched and defines no LICENSE_FILES, we will extract and patch it for nothing. There is no easy way to know whether we have to patch a package or not. We can only either duplicate the logic to detect patches (bad) or rely on the infra actually patching the package. Also, a vast majority of packages are either patched, or define _LICENSE_FILES, so it is best and easiest to always extract and patch them prior to legal-info. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Tested-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* support/apply-patches: bail-out on duplicate patch basenamesYann E. MORIN2016-06-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patches we save can come from various locations: - bundled with Buildroot - downloaded - from one or more global-patch-dir It is possible that two patches lying into different locations have the same basename, like so (first is bundled, second is from an hypothetical global-patch-dir): package/foo/0001-fix-Makefile.patch /path/to/my/patches/foo/0001-fix-Makefile.patch In that case, when running legal-info, we'd save only the second patch, overwriting the first. That would be problematic, because: - either the second patch depends on the first, and thus would no longer apply (this is easy to detect, though), - or the second patch does not depend on the first, and the compliance delivery will not be complete (this is much harder to detect). We fix that by checking that no two patches have the same same basename. If we find that the basename of the patch to be applied collides with that of a previously applied patch, we error out and report the duplicate. The unfortunate side-effect is that existing setups will now break in that situation, but that's a minor, corner-case issue that is easily fixed. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: adjust coding style, fix minor typos in the commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud