Hi, Nishanth Menon <n...@ti.com> writes: > Hi Masahiro-san, > > On Tue, Mar 28, 2017 at 1:29 AM, Masahiro Yamada > <yamada.masah...@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. -- balbi _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
