[U-Boot] [PATCH v4 32/37] Makefile: refactor tools-all targets
Gerhard Sittig
gsi at denx.de
Fri Jan 10 15:26:01 CET 2014
On Fri, Jan 10, 2014 at 15:44 +0900, Masahiro Yamada wrote:
>
> - Move "easylogo", "env", "gdb" tagets to tools/Makefile
> - Delete "gdbtools" target (same as "gdb")
This appears to be an "incompatible" change with regards to how
users can compile these tools. Please see tools/env/README and
update it as well. I'm aware of external projects which grab a
U-Boot source tree and 'make env' to just get the fw_printenv(1)
binary.
There is another issue for those who do
make HOSTCC=${CROSS_COMPILE}gcc env
(needs a HOSTSTRIP spec as well in recent mainline sources)
to get an fw_printenv(1) binary that runs on the target (in
contrast to the build machine). Some yocto recipes do this, to
not re-invent how to build this tool or how to read and write the
environment image.
With your changes, the 'env' make target is gone, instead there
is a 'tools-all' target but it has a wider scope, includes the
BMP manipulation/conversion stuff and uses HOSTCC to build a
bmp_logo(1) tool, which breaks in the mentioned use case (cross
compiled bmp_logo(1) executable, empty bmp_logo.h header, aborted
build sequence).
Can you please look into whether the sources in the tools/env/
directory can get compiled without involving other directories?
I tried 'make tools/env/', but this "make dir/" syntax as known
from kernel builds appears to not be supported in U-Boot (yet? or
have I done something wrong?). I did a quick hack and extended
the top level Makefile as outlined below (diff copied here with
the clipboard, whitespace will be broken, build tested but not
yet run tested, only checked file(1) output).
--- a/Makefile
+++ b/Makefile
@@ -1124,6 +1124,9 @@ xmldocs pdfdocs psdocs htmldocs mandocs: tools/kernel-doc/docproc
tools-all: $(VERSION_FILE) $(TIMESTAMP_FILE)
$(Q)$(MAKE) $(build)=tools HOST_TOOLS_ALL=y
+tools-env: $(VERSION_FILE) $(TIMESTAMP_FILE)
+ $(Q)$(MAKE) $(build)=tools/env
+
.PHONY : CHANGELOG
CHANGELOG:
git log --no-merges U-Boot-1_1_5.. | \
While testing your series I noticed a probably missing
dependency: Running something different from 'make all' (or make
without a target spec) after 'make <board>_config' won't work
since the fixdeps(1) tool is missing. It's a "byproduct" of
'make all', afterwards other targets can get built separately.
Is there a "preparation" step that one needs to take if not
calling 'make all' immediately after configuration?
For the record: My test was with your v4 series on top of
v2014.01-rc2-43-ge7be18225fbe plus your "sandbox: Use system
headers first for sandbox's os.c in a different way" change, with
ELDK 5.3 and a PowerPC target.
$ . /opt/eldk-5.3-qte/powerpc/environment-setup-powerpc-linux
$ env -u LDFLAGS ARCH=powerpc CROSS_COMPILE=$TARGET_PREFIX $SHELL
$ mkdir output-ac14xx && cd $_
$ make -C .. O=`pwd` ac14xx_config
$ make HOSTCC=${CROSS_COMPILE}gcc tools/env/
"Nothing to be done ..."
$ make HOSTCC=${CROSS_COMPILE}gcc tools-all
HOSTCC tools/easylogo/easylogo
/bin/sh: 1: scripts/basic/fixdep: not found
make[4]: *** [tools/easylogo/easylogo] Error 127
make[3]: *** [tools/easylogo] Error 2
make[2]: *** [tools-all] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
$ make HOSTCC=${CROSS_COMPILE}gcc tools
CC lib/asm-offsets.s
GEN include/generated/generic-asm-offsets.h
CC /asm-offsets.s
touch: cannot touch `/asm-offsets.s': Permission denied
make[2]: *** [/asm-offsets.s] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
[ identical errors without the HOSTCC spec ]
$ time make
...
HOSTCC scripts/basic/fixdep
...
[ native tools/ gets built as well, but not tools/env/ it seems ]
$ make HOSTCC=${CROSS_COMPILE}gcc tools-all
...
tools/bmp_logo: 1: tools/bmp_logo: ELF: not found
tools/bmp_logo: 2: tools/bmp_logo: Syntax error: "(" unexpected
...
$ $EDITOR ../Makefile
$ make tools-all
$ make HOSTCC=${CROSS_COMPILE}gcc tools-env
$ file tools/env/fw_printenv
tools/env/fw_printenv: ELF 32-bit MSB executable, PowerPC or cisco 4500 [ ... ]
Let me say that I do appreciate the work that you spend to
provide us all with the comfort of Kbuild and "real"
out-of-source builds, and cleaned up build infrastructure for
improved maintenance, and future Kconfig support. :-]
I will report back after doing run time tests.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
More information about the U-Boot
mailing list