Hi,
Nishanth Menon nm@ti.com writes:
Hi Masahiro-san,
On Tue, Mar 28, 2017 at 1:29 AM, Masahiro Yamada yamada.masahiro@socionext.com wrote: [...]
When O= is given, the build system runs in the object tree, not in the source tree. (This is the same as Linux.)
If you see the top Makefile:
ifeq ($(KBUILD_SRC),) # building in the source tree srctree := . else ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR))) # building in a subdirectory of the source tree srctree := .. else srctree := $(KBUILD_SRC) endif endif
If O= points to a sub-directory of the source tree, the relative path "srctree := .." is used.
Otherwise, the absolute path srctree := $(KBUILD_SRC) is used. In your case, "O=../b" means the source tree and the obj tree are siblings. So, absolute path.
I did simplify this a bit with O=../b to highlight exactly what you mentioned above. in our case, the O=path points to a completely different directory path.
If you want to see a short relative path for __FILE__, I'd recommend to use a sub-directory for O=.
For example, your source tree is located at ~/aaaaaaaaa/bbbbbbb/cccccccc/u-boot, create a directory ~/aaaaaaaaa/bbbbbbb/cccccccc/u-boot/foo, then give O=foo
Typical product build such as OE recipes used (in our case) does not build into the source folder, instead, all binary builds are pointed to either a temporary location or a package build location. So, while O=source_path/build would aliviate the problem, it still does'nt really solve the root of the issue.
have you tried using __BASE_FILE__ instead of __FILE__? You could also redefine __FILE__ or __BASE_FILE__ while building SPL.