[U-Boot] __FILE__ usage and and SPL limits for SRAM

[Nishanth Menon]

Hi Masahiro-san,

On Tue, Mar 28, 2017 at 1:29 AM, Masahiro Yamada
<yamada.masahiro at 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.

-- 
---
Regards,
Nishanth Menon