1. 09 Aug, 2018 2 commits
  2. 07 Aug, 2018 3 commits
    • Masahiro Yamada's avatar
      um: clean up archheaders recipe · 0004438a
      Masahiro Yamada authored
      Now that '%asm-generic' is added to no-dot-config-targets,
      'make asm-generic' does not include the kernel configuration.
      
      You can simply do 'make asm-generic' in the recursed top Makefile
      without bothering syncconfig.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Acked-by: default avatarRichard Weinberger <richard@nod.at>
      0004438a
    • Masahiro Yamada's avatar
      kbuild: add %asm-generic to no-dot-config-targets · 63e31a67
      Masahiro Yamada authored
      asm-generic and uapi-asm-generic do not depend on the kernel
      configuration.  In fact, uapi-asm-generic is the prerequisite of
      headers_{install,check}, hence it should not require the .config file.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Acked-by: default avatarRichard Weinberger <richard@nod.at>
      63e31a67
    • Masahiro Yamada's avatar
      um: fix parallel building with O= option · 13d3d01e
      Masahiro Yamada authored
      Randy Dunlap reports UML occasionally fails to build with -j<N> and
      O=<builddir> options.
      
        make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64'
          UPD     include/generated/uapi/linux/version.h
          WRAP    arch/x86/include/generated/asm/dma-contiguous.h
          WRAP    arch/x86/include/generated/asm/export.h
          WRAP    arch/x86/include/generated/asm/early_ioremap.h
          WRAP    arch/x86/include/generated/asm/mcs_spinlock.h
          WRAP    arch/x86/include/generated/asm/mm-arch-hooks.h
          WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
          WRAP    arch/x86/include/generated/uapi/asm/poll.h
          GEN     ./Makefile
        make[2]: *** No rule to make target 'archheaders'.  Stop.
        arch/um/Makefile:119: recipe for target 'archheaders' failed
        make[1]: *** [archheaders] Error 2
        make[1]: *** Waiting for unfinished jobs....
          UPD     include/config/kernel.release
        make[1]: *** wait: No child processes.  Stop.
        Makefile:146: recipe for target 'sub-make' failed
        make: *** [sub-make] Error 2
      
      The cause of the problem is the use of '$(MAKE) KBUILD_SRC=',
      which recurses to the top Makefile via the $(objtree)/Makefile
      generated by scripts/mkmakefile.
      
      When you run "make -j<N> O=<builddir> ARCH=um", Make can execute
      'archheaders' and 'outputmakefile' targets simultaneously because
      there is no dependency between them.
      
      If it happens,
      
        $(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders
      
      ... tries to run $(objtree)/Makefile that is being updated.
      
      The correct way for the recursion is
      
        $(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders
      
      ..., which does not rely on the generated Makefile.
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Acked-by: default avatarRichard Weinberger <richard@nod.at>
      13d3d01e
  3. 29 Jul, 2018 1 commit
  4. 28 Jul, 2018 14 commits
  5. 20 Jul, 2018 1 commit
    • Dirk Gouders's avatar
      kbuild: if_changed: document single use per target limitation · bb81955f
      Dirk Gouders authored
      Users of if_changed could easily feel invited to use it to divide a
      recipe into parts like:
      
      a: prereq FORCE
      	$(call if_changed,do_a)
      	$(call if_changed,do_b)
      
      But this is problematic, because if_changed should not be used more
      than once per target: in the above example, if_changed stores the
      command-line of the given command in .a.cmd and when a is up-to-date
      with respect to prereq, the file .a.cmd contains the command-line for
      the last command executed, i.e. do_b.
      
      When the recipe is then executed again, without any change of
      prerequisites, the command-line check for do_a will fail, do_a will be
      executed and stored in .a.cmd.  The next check, however, will still see
      the old content (the file isn't re-read) and if_changed will skip
      do_b, because the command-line test will not recognize a change.  On
      the next execution of the recipe the roles will flip: do_a is OK but
      do_b not and it will be executed.  And so on...
      Signed-off-by: default avatarDirk Gouders <dirk@gouders.net>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      bb81955f
  6. 18 Jul, 2018 6 commits
  7. 17 Jul, 2018 12 commits
  8. 15 Jul, 2018 1 commit