summaryrefslogtreecommitdiffstats
path: root/rules.mk
Commit message (Collapse)AuthorAgeFilesLines
* kbuild: delete temporary build scriptsMasahiro Yamada2014-02-191-47/+0
| | | | | | | We had switched to Kbuild. We do not need old build scripts any more. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* kbuild: change out-of-tree buildMasahiro Yamada2014-02-191-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the working directory where the build process occurs. Before this commit, build process occurred under the source tree for both in-tree and out-of-tree build. That's why we needed to add $(obj) prefix to all generated files in makefiles like follows: $(obj)u-boot.bin: $(obj)u-boot Here, $(obj) is empty for in-tree build, whereas it points to the output directory for out-of-tree build. And our old build system changes the current working directory with "make -C <sub-dir>" syntax when descending into the sub-directories. On the other hand, Kbuild uses a different idea to handle out-of-tree build and directory descending. The build process of Kbuild always occurs under the output tree. When "O=dir/to/store/output/files" is given, the build system changes the current working directory to that directory and restarts the make. Kbuild uses "make -f $(srctree)/scripts/Makefile.build obj=<sub-dir>" syntax for descending into sub-directories. (We can write it like "make $(obj)=<sub-dir>" with a shorthand.) This means the current working directory is always the top of the output directory. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Gerhard Sittig <gsi@denx.de>
* tools: convert makefiles to kbuild styleMasahiro Yamada2014-02-191-5/+0
| | | | | | | | | | | | | Before this commit, makefiles under tools/ directory were implemented with their own way. This commit refactors them by using "hostprogs-y" variable. Several C sources have been added to wrap other C sources to simplify Makefile. For example, tools/crc32.c includes lib/crc32.c Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* Licenses: introduce SPDX Unique Lincense IdentifiersWolfgang Denk2013-07-241-19/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like many other projects, U-Boot has a tradition of including big blocks of License headers in all files. This not only blows up the source code with mostly redundant information, but also makes it very difficult to generate License Clearing Reports. An additional problem is that even the same lincenses are referred to by a number of slightly varying text blocks (full, abbreviated, different indentation, line wrapping and/or white space, with obsolete address information, ...) which makes automatic processing a nightmare. To make this easier, such license headers in the source files will be replaced with a single line reference to Unique Lincense Identifiers as defined by the Linux Foundation's SPDX project [1]. For example, in a source file the full "GPL v2.0 or later" header text will be replaced by a single line: SPDX-License-Identifier: GPL-2.0+ We use the SPDX Unique Lincense Identifiers here; these are available at [2]. Note: From the legal point of view, this patch is supposed to be only a change to the textual representation of the license information, but in no way any change to the actual license terms. With this patch applied, all files will still be licensed under the same terms they were before. Note 2: The apparent difference between the old "COPYING" and the new "Licenses/gpl-2.0.txt" only results from switching to the upstream version of the license which is differently formatted; there are not any actual changes to the content. Note 3: There are some recurring questions about linense issues, such as: - Is a "All Rights Reserved" clause a problem in GPL code? - Are files without any license header a problem? - Do we need license headers at all? The following excerpt from an e-mail by Daniel B. Ravicher should help with these: | Message-ID: <4ADF8CAA.5030808@softwarefreedom.org> | Date: Wed, 21 Oct 2009 18:35:22 -0400 | From: "Daniel B. Ravicher" <ravicher@softwarefreedom.org> | To: Wolfgang Denk <wd@denx.de> | Subject: Re: GPL and license cleanup questions | | Mr. Denk, | | Wolfgang Denk wrote: | > - There are a number of files which do not include any specific | > license information at all. Is it correct to assume that these files | > are automatically covered by the "GPL v2 or later" clause as | > specified by the COPYING file in the top level directory of the | > U-Boot source tree? | | That is a very fact specific analysis and could be different across the | various files. However, if the contributor could reasonably be expected | to have known that the project was licensed GPLv2 or later at the time | she made her contribution, then a reasonably implication is that she | consented to her contributions being distributed under those terms. | | > - Do such files need any clean up, for example should we add GPL | > headers to them, or is this not needed? | | If the project as a whole is licensed under clear terms, you need not | identify those same terms in each file, although there is no harm in | doing so. | | > - There are other files, which include both a GPL license header | > _plus_ some copyright note with an "All Rights Reserved" clause. It | > has been my understanding that this is a conflict, and me must ask | > the copyright holders to remove such "All Rights Reserved" clauses. | > But then, some people claim that "All Rights Reserved" is a no-op | > nowadays. License checking tools (like OSLC) seem to indicate this is | > a problem, but then we see quite a lot of "All rights reserved" in | > BSD-licensed files in gcc and glibc. So what is the correct way to | > deal with such files? | | It is not a conflict to grant a license and also reserve all rights, as | implicit in that language is that you are reserving all "other" rights | not granted in the license. Thus, a file with "Licensed under GPL, All | Rights Reserved" would mean that it is licensed under the GPL, but no | other rights are given to copy, modify or redistribute it. | | Warm regards, | --Dan | | Daniel B. Ravicher, Legal Director | Software Freedom Law Center (SFLC) and Moglen Ravicher LLC | 1995 Broadway, 17th Fl., New York, NY 10023 | (212) 461-1902 direct (212) 580-0800 main (212) 580-0898 fax | ravicher@softwarefreedom.org www.softwarefreedom.org [1] http://spdx.org/ [2] http://spdx.org/licenses/ Signed-off-by: Wolfgang Denk <wd@denx.de>
* Correct dependency rule to fix SPL buildSimon Glass2011-10-181-1/+2
| | | | | | | | | | | | | Commit 4750884 introduced a change in the dependency generation which breaks SPL, because the source files being built are not initially present and are symlinked as part of the build. The .depend file must depend not only on the files in the DEPS list but also on the sources which did not contribute files to the DEPS list, since these sources will otherwise not get a dependency and will not be built. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Wolfgang Denk <wd@denx.de>
* Adjust dependency rules to permit per-file flagsSimon Glass2011-10-171-11/+33
| | | | | | | | | | | | | | The dependency rules are currently done in a shell 'for' loop. This does not permit Makefile variables to adjust preprocessor flags as is done with normal compile flags, using the CFLAGS_path/file.o syntax. This change moves the dependency generation into the Makefile itself, and permits a CPPFLAGS_path/file.o to adjust preprocessor flags on a file or directory basis. The CPPFLAGS_... variable is also folded into CFLAGS during the build. Signed-off-by: Simon Glass <sjg@chromium.org>
* Makefile : fix generation of cpu related asm-offsets.hStefano Babic2011-09-071-10/+0
| | | | | | | | | | | commit 0edf8b5b2fa0d210ebc4d6da0fd1aceeb7e44e47 breaks building on a different directory with the O= parameter. The patch wil fix this issue, generating always asm-offsets.h before the other targets. Signed-off-by: Stefano Babic <sbabic@denx.de> CC: Matthias Weisser <weisserm@arcor.de> CC: Wolfgang Denk <wd@denx.de>
* rules.mk: replace GNU specific \w with POSIX equivalantJeroen Hofstee2011-07-281-2/+2
| | | | | | | | | | If sed does not support the GNU \w regex extension, build attempts lead to circular dependency warnings and finally build failure (crc32.c not found). Build output before and after the patch on FreeBSD is at: http://lists.denx.de/pipermail/u-boot/2011-June/095235.html Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
* build: Add targets for auto gen of asm-offsets.h and use it in imx35Matthias Weisser2011-07-141-0/+10
| | | | | | | | asm-offsets.h should be auto generated. This patch adds two rules to rules.mk which makes this possible and removes the rules on imx35. Signed-off-by: Matthias Weisser <weisserm@arcor.de> Acked-by: Stefano Babic <sbabic@denx.de>
* rules.mk: make sure we always create a .depend fileWolfgang Denk2010-10-061-0/+1
| | | | | | | | | | | There are some cases where "make depend" would always run when entering a directory. This happened when both the $(SRCS) and $(HOSTSRCS) lists were empty (which is for example typical for the examples/api/ directory). Avoid this by making sure that a ".depend" file gets always created, even if empty. Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Detlev Zundel <dzu@denx.de>
* makefiles: fixes for building build toolsScott Wood2009-12-021-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, some of the tools instead set CC to be HOSTCC in order to re-use some pattern rules -- but this fails when the user overrides CC on the make command line. Also, the HOSTCFLAGS in tools/Makefile are currently not being used because config.mk overwrites them. This patch adds static pattern rules for files that have been requested to be built with the native compiler using $(HOSTSRCS) and $(HOSTOBJS), and converts the tools to use them. It restores easylogo to using the host compiler, which was broken by commit 38d299c2db81bd889c601b5dfc12c4e83ef83333 (if this was an intentional change, please let me know -- but it seems to be a build tool). It restores -pedantic and the special flags for darwin and cygwin that were requested in tools/makefile (but keeps the flags added by config.mk) -- hopefully someone can test this on those platforms. It no longer conditionalizes -pedantic on not being darwin; it wasn't clear that that was intentional, and unless there's a real problem it's just inviting people to contribute non-pedantic patches to those files (I'm not a fan of -pedantic personally, but if it's on for one platform it should be on for all). HOST_LDFLAGS is renamed HOSTLDFLAGS for consistency with the previous HOST_CFLAGS to HOSTCFLAGS rename. A new HOSTCFLAGS_NOPED is made available for those files which currently cannot be built with -pedantic, and replaces the old FIT_CFLAGS. imls now uses the cross compiler properly, rather than by trying to reconstruct CC using the typoed $(CROSS_COMPILER). envcrc.c is now dependency-processed unconditionally -- previously it would be built without being on (HOST)SRCS if CONFIG_ENV_IS_EMBEDDED was not selected. Signed-off-by: Scott Wood <scottwood@freescale.com>
* unify HOST_CFLAGS and HOSTCFLAGSMike Frysinger2009-07-231-1/+1
| | | | | | | | The top build system sets up HOSTCFLAGS a bit and exports it, but other places use HOST_CFLAGS instead. Unify the two as HOSTCFLAGS so that the values stay in sync. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* Add support for a saving build objects in a separate directory.Marian Balakowicz2006-09-011-0/+35
Modifications are based on the linux kernel approach and support two use cases: 1) Add O= to the make command line 'make O=/tmp/build all' 2) Set environement variable BUILD_DIR to point to the desired location 'export BUILD_DIR=/tmp/build' 'make' The second approach can also be used with a MAKEALL script 'export BUILD_DIR=/tmp/build' './MAKEALL' Command line 'O=' setting overrides BUILD_DIR environent variable. When none of the above methods is used the local build is performed and the object files are placed in the source directory.
OpenPOWER on IntegriCloud