summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)Author
2017-02-15package: add generic support for lz archivesBaruch Siach
This commit teaches the generic package handling code how to extract .tar.lz archives. When lzip is not installed on the host, host-lzip gets built automatically. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-14package/ccache: do not force colored diagnosticsYann E. MORIN
When GCC_COLORS is set, ccache passes '-fdiagnostics-color' to GCC but this flag requires GCC v4.9 or later. Older versions complain about the unrecognized command line option. Using GCC_COLORS in the context of Buildroot is seldom useful, so we just unexport GCC_COLORS altogether. Reported-by: Carlos Santos <casantos@datacom.ind.br> 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> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-11Prepare for 2017.02-rc1Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07reproducible: enable fakedateJérôme Pouiller
Enable fakedate for whole build process. This work was sponsored by `BA Robotic Systems'. Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-27Makefile, manual: Bump copyright yearPeter Korsgaard
Happy 2017! Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-25arch: add OpenRISC architecture supportWaldemar Brodkorb
Add support for OpenRISC. See here for more details about OpenRISC http://openrisc.io. All buildroot included upstream binutils versions are supported. Gcc support is not upstream, to be able to enable musl C library support later, we use the branch with musl support. At the moment it is possible to build a musl based toolchain, but bootup in Qemu fails. Gdb is only working to debug bare-metal code, there is no support for gdbserver/gdb on Linux, yet. [Peter: drop ?= for GCC_SOURCE] Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Tested-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-06Makefile: move SED definition into the main MakefileThomas Petazzoni
Since commit f71a621d91ec27f175fc84012962f88b1107305f, we are using the SED variable in the main Makefile. However, this variable is only defined in package/Makefile.in, which gets included only when a configuration is defined. This means that, if you do: $ make menuconfig savedefconfig without a configuration defined, it fails with: /bin/bash: /BR2_DEFCONFIG=/d: No such file or directory Makefile:898: recipe for target 'savedefconfig' failed make[1]: *** [savedefconfig] Error 127 This issue affects users of the "buildroot-submodule" project, which does menuconfig+savedefconfig automatically. They worked around this issue in commit https://github.com/Openwide-Ingenierie/buildroot-submodule/commit/d12676b608a58529c6b551aa176464166a200428, but really "make menuconfig savedefconfig" should work out of the box. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-01Merge branch 'next'Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-01Kickoff 2017.02 cyclePeter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-11-30Update for 2016.11Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-11-28Update for 2016.11-rc3Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-11-27Makefile: drop redundant shell call when deriving BASE_DIRDanomi Manchego
Commit 173135df5b69dfd5ae6fe6cf2de8833c6f74c143 ("core: re-enter make if $(CURDIR) or $(O) are not canonical paths") introduced the CANONICAL_O variable, defined as: CANONICAL_O := $(shell mkdir -p $(O) >/dev/null 2>&1)$(realpath $(O)) This duplicates the definition of BASE_DIR, by different means: BASE_DIR := $(shell mkdir -p $(O) && cd $(O) >/dev/null && pwd) So one of these shell calls is redundant. CANONICAL_O is defined first, so this commit replaces the BASE_DIR derivation with $(CANONICAL_O). Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23Makefile: fix distclean removal of $(O)Danomi Manchego
The distclean target no longer removes the "output" directory for in-tree builds, because $(O) is no longer just "output" in that case. Change the test to be against "$(CURDIR)/output", to match the O setting, and a similar test elsewhere in the same Makefile. Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23Makefile: fix ignored trace at target-finalizeGaël PORTAY
Make may throw an error (but ignored) trace when cleaning up the rootfs. The target-finalize rule intends to remove the folder `$(TARGET_DIR)/usr/share' but this directory may still contain items (such as the `udhcpc' helper script) and causes the rmdir to fail. The stderr output is redirected to /dev/null but it returns and error which is escaped by the leading `-'; but make reports an ignored-error. See the log below: $ make (...) rm -rf (...)/target/usr/share/gtk-doc rmdir (...)/target/usr/share rmdir: failed to remove '(...)/target/usr/share': Directory not empty make[1]: [Makefile:650: target-finalize] Error 1 (ignored) find /(...)/target -type f \( -perm /111 -o -name '*.so*' \) -not \( -name 'libpthread*.so*' -o -name 'ld-*.so*' -o -name '*.ko' \) -print0 | xargs -0 (...)/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-strip --remove-section=.comment --remove-section=.note 2>/dev/null || true This patch apply the same rule at the instruction immediately after: * redirecting stderr to /dev/null (already done) and * executing true if the `rmdir' instruction fails. Signed-off-by: Gaël PORTAY <gael.portay@savoirfairelinux.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23Makefile: make exported variable definitions consistentJérôme Pouiller
Use a space before and after the equal sign when defining the TZ, LANG and LC_ALL variables, as suggested by the Buildroot coding style. Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23Makefile: add '-n' to gzip invocations to improve reproducibilityJérôme Pouiller
Default invocation to gzip include timestamp in output file. This feature is incompatible with BR2_REPRODUCIBLE. It is possible to disable it with '-n'. The environment variable GZIP can hold a set of default options for gzip. So instead to find all gzip invocation in build process, we just export 'GZIP=-n'. Notice bzip2, lzma and xz are not impacted by this problem. On the other hand, lzop does include timestamp and does not provide any way to disable it. This work was sponsored by `BA Robotic Systems'. Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-23Makefile: generate SOURCE_DATE_EPOCH for reproducible buildsGilles Chanteperdrix
When reproducibility is requested, generate a global SOURCE_DATE_EPOCH environment variable which contains either the date of Buildroot last commit if running from a git repository, or the latest release date. This means that all packages embedding build dates will appear to have the same build date, so in case of new commit or release, all packages will appear to have been changed, even though some of them may not have changed in fact. The meaning of SOURCE_DATE_EPOCH is specified by the following specification: https://reproducible-builds.org/specs/source-date-epoch/ Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-15Makefile: add missing targets to noconfig_targets and nobuild_targetsRahul Jain
currently some buildroot targets fails (list-defconfigs, graph-build, etc), if there is an issue with configuration. For example, enabling uboot package without providing custom version name results in failing of various targets. Signed-off-by: Rahul Jain <Rahul.Jain@imgtec.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: as suggested by Arnout, added printvars and savedefconfig to nobuild_targets.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-13Update for 2016.11-rc2Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09Makefile: fix stripping of ld.so and libpthread for merged /usrJérôme Pouiller
If 'lib' is a symlink (as is the case when BR2_ROOTFS_MERGED_USR=y), 'find lib' does not return the correct result. So, until now, libpthread*.so* and ld-*.so* were not stripped when 'lib' was a symlink. We fix this by using 'find lib/' instead of 'find lib'. For consistency reason, we also do the same change for the 'find' that removes .a and .la files. Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> [Thomas: slightly improved the commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-05Makefile: delete default rulesArnout Vandecappelle
We don't use the default implicit rules that are added by make, so they just slow down the Makefile processing. The default implicit rules can be removed by defining an empty .SUFFIXES: target. This speeds up the start of the build on my machine from 5.6s to 4.9s. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-03Update for 2016.11-rc1Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-03core: remove redundant "override O := $(O)"Arnout Vandecappelle
The top-level Makefile contains an "override O := $(O)" statement that is purportedly required to make sure the O flag doesn't leak into the environment of sub-makes. However, since commit 173135d, there is already an "override O := ..." a few lines down. Therefore, the first override is redundant. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-03core: don't reset MAKEOVERRIDES when re-entering makeArnout Vandecappelle
We reset MAKEOVERRIDES to avoid passing down variables that are overridden on the command line to the package build systems. Indeed, the variables overridden on the command line will be Buildroot variables and not relevant to the package build system. In particular the O option is used by some packages and the value passed in on the command line is plain wrong for the individual package. However, in commit 916e614b, MAKEOVERRIDES was moved earlier and it was reset _before_ re-entering make in the cases when something has to be fixed up (incorrect umask, non-absolute paths in O or CURDIR). Therefore, if make is re-entered, any command line overrides are lost. This particularly bites the autobuilders, because they use O=<relative path> to specify the output directory, and they add BR2_JLEVEL=... to avoid starting too many jobs in parallel. The BR2_JLEVEL override is lost. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Tested-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-25core/graph-depends: add option to graph reverse dependenciesYann E. MORIN
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>
2016-10-25pkg-infra: allow dumping reverse dependencies of a packageYann E. MORIN
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" <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>
2016-10-19core: re-enter make if $(CURDIR) or $(O) are not canonical pathsSamuel Martin
When $(CURDIR) and/or $(O) contain symlinks in their paths, they can be resolved differently, depending on each package build-system (whether it uses the given paths or get the absolute canonical ones). Using absolute canonical paths will help achieving reproducible builds and will make easier tracking down host machine paths leaking into the host, target or staging trees. So, this change ensures the build takes place with the CURDIR and O variables are set to their absolute canonical paths. In order to recall the toplevel makefile with absolute canonical paths for $(CURDIR) and $(O), we need to: 1- Compute the absolute canonical paths for $(CURDIR) and $(O) that will be passed to the sub-make. This is achieved using the 'realpath' make primitive. However, some care must be taken when manipulating O: - the out-of-tree makefile wrapper happens a trailing "/.", we need to strip this part away to not break the comparison driving the sub-make call; - the user can leave a trailing '/' to $(O); - according to [1,2], realpath returns an empty string in case of non-existing entry. So, to avoid passing an empty O= variable to sub-make, it is necessary to define the output directory and create it prior to call realpath on it (because on the first invocation, $(O) usually does not yet exists), hence the trick doing the mkdir right before calling realpath. 2- Update EXTRAMAKEARGS with the absolute canonical $(O) and use it when call recalling the top-level makefile with umask and paths correctly set. 3- Lastly, update the condition for setting the CONFIG_DIR and NEED_WRAPPER variables. Note: * This change takes care of the makefile wrapper installed in $(O) to avoid unneeded make recursion. [1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html [2] http://man7.org/linux/man-pages/man3/realpath.3.html Reported-by: Matthew Weber <matt@thewebers.ws> Cc: Matthew Weber <matt@thewebers.ws> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-19core: reorder top-level Makefile and document thingsSamuel Martin
This change only moves things around and comments what is done in the top-level Makefile file, in order to prepare the next changes. Note that moving the definition of $(O) before or after re-entering make does not change anything on the buildroot behavior. This change also renames the variable UMASK to REQ_UMASK. Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-19core: split variables definition related to in/out-of-tree build from O itselfSamuel Martin
This change uncorrolates the CONFIG_DIR and NEED_WRAPPER definition from the presence of the O variable in the command line. Now, the condition used to set these variables is the value of O itself. This change is a preparatory work since the O definition will need to be moved around when we will make Buildroot run with absolute canonical paths for both its root directory and the output location. This will be addressed in a follow-up patch. Signed-off-by: Samuel Martin <s.martin49@gmail.com> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16core: support description for br2-external treesYann E. MORIN
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-16core: allow a br2-external tree to override a defconfigYann E. MORIN
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>
2016-10-16core: add support for multiple br2-external treesYann E. MORIN
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>
2016-10-16core: introduce per br2-external NAMEYann E. MORIN
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>
2016-10-16core: offload handling of BR2_EXTERNAL into the scriptYann E. MORIN
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>
2016-10-16core: get rid of our dummy br2-external treeYann E. MORIN
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>
2016-10-16core: do not hard-code inclusion of br2-external in KconfigYann E. MORIN
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>
2016-10-15Remove BR2_DEPRECATEDArnout Vandecappelle
The BR2_DEPRECATED logic is a lot less useful than the legacy handling, because the symbols just disappears without warning to the user. For example, we had a few defconfigs that were using deprecated symbols (which were not actually used because BR2_DEPRECATED wasn't set) so these didn't build the expected code anymore. Also, the idea behind BR2_DEPRECATED is that you can easily revive it again if there is interest. However, it is relatively easy to revert the removal of a package as well. The deprecation is also more effort because it has to be removed twice: once when deprecating, and once when really removing. It doesn't make sense to add a legacy entry for BR2_DEPRECATED. Users who actually used it will get legacy warnings instead. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15core/legal-info: don't generate big file with all license textsYann E. MORIN
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 <thomas.petazzoni@free-electrons.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-19linux: use INSTALL_MOD_STRIP=1 to strip modulesAlexey Brodkin
We used to do a special handling of Linux kernel modules when stripping target binaries because there's some special precious data in modules that we must keep for them to properly operate. This is for example true for stack unwinding data etc. It turned out there're cases when our existing "strip --strip-unneeded" doesn't work well. For example this removes .debug_frame section used by Linux on ARC for stack unwinding, refer to [1] and [2] for more details. Now Linux kernel may strip modules as a part of "modules_install" target if INSTALL_MOD_STRIP=1 is passed in command line. And so we'll do allowing kernel decide how to strip modules in the best way. Still note as of today Linux kernel strips modules uniformly for all arches with "strip" command, so this commit alone doesn't solve mentioned problem but it opens a possibility to add later a patch to the kernel which will strip modules for ARC differently - and that's our plan for mainline kernel. [1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86 [2] http://lists.busybox.net/pipermail/buildroot/2016-September/172161.html Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Daniel Mentz <danielmentz@google.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-17core: distclean is a noconfig targetYann E. MORIN
When the .config contains invalid configuration *(e.g. two providers for a same virtual package), it is not possible to run "make distclean" because the .config file is sourced and packages interpreted in this case. Add distclean to the noconfig list, so that we can run it in all cases. However, this meand that DL_DIR is no longer set, and thus the default download location never removed. We fix that by always removing the download location, so that if it is the one configured we still remove it (no change) and if it is not the one configured, we remove an non-existing location and leave the user's location intact (no change either). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-02Merge branch 'next'Peter Korsgaard
Quite some conflicts, so here goes .. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-01Kickoff 2016.11 cyclePeter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-01Update for 2016.08Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-30Update for 2016.08-rc3Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-27core: introduce a generated kconfig snippetYann E. MORIN
Add the infrastructure for adding generated kconfig snippet in the menuconfig. For now, the kconfig snippet is generated empty, the recipe for filling it in will be introduced in sub-sequent patches. 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> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27core: move rule to create basic directoriesYann E. MORIN
Some of those directories will be needed even during configuration, like BUILD_DIR, where we'll store the generated kconfig snippet. So, move the rule to create them outside the BR2_HAVE_DOT_CONFIG block. 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> [Thomas: fixup commit log, as noticed by Romain Naour.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27core: introduce an intermediate rule before the configuratorsYann E. MORIN
Currently, all configurators depend on generating the out-of-tree Makefile wrapper. In an upcoming patch, we'll need to also generate a kconfig fragment, so it will have to kick in before we run the configurators. Introduce a new intermediate "prepare-kconfig" rule, so we can commonalise the dependencies of the configurators. Move the dependency on the Makefile wrapper to that new intermediate rule. 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> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Thomas: mark prepare-kconfig as a phony target.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27core: commonalise the bundled and br2-external %_defconfig rulesYann E. MORIN
The code for both cases is exactly the same, and only differs in the location where defconfig files are looked for. We use an intermediate macro to generate the corresponding rules, because directly generating the rules is ugly and needs lots of escaping and double-dollar-ing for the $(eval ...) and $(foreach ...) calls to play nicely together. Furthermore, that will be tremendously useful when we support multiple br2-external trees. 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> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Thomas: move comment outside of the make target, so that it isn't displayed on stdout when loading a defconfig.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27core: move pkg-utils.mk to support/Yann E. MORIN
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>
2016-08-17Update for 2016.08-rc2Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>