From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Date: Tue, 28 Mar 2017 06:20:53 -0500 Subject: [U-Boot] __FILE__ usage and and SPL limits for SRAM In-Reply-To: References: <7522fff3-a33e-21bd-00fe-55c03b4169c1@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Masahiro-san, On Tue, Mar 28, 2017 at 1:29 AM, Masahiro Yamada 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