24 Jul, 2013

1 commit

  • 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:
    | Date: Wed, 21 Oct 2009 18:35:22 -0400
    | From: "Daniel B. Ravicher"
    | To: Wolfgang Denk
    | 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

    Wolfgang Denk
     

19 Oct, 2011

1 commit

  • 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
    Tested-by: Wolfgang Denk

    Simon Glass
     

18 Oct, 2011

1 commit

  • 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

    Simon Glass
     

08 Sep, 2011

1 commit


29 Jul, 2011

1 commit


14 Jul, 2011

1 commit


07 Oct, 2010

1 commit

  • 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
    Acked-by: Detlev Zundel

    Wolfgang Denk
     

03 Dec, 2009

1 commit

  • 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

    Scott Wood
     

24 Jul, 2009

1 commit


02 Sep, 2006

1 commit

  • 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.

    Marian Balakowicz