[U-Boot] [PATCH] Makefile: Include vendor common library in include search path
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com ---
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote:
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Regards, Simon
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote:
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Hmmm... Are folks ok if I create a softlink?
2015-11-06 12:30 GMT+09:00 Nishanth Menon nm@ti.com:
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote:
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Hmmm... Are folks ok if I create a softlink?
Or, you can maybe add the following into board/ti/am57xx/Makefile.
subdir-ccflags-y := -I$(src)/../common
then, you can use #include <xyz.h> from your board/ti/am57xx/board.c
But, I personally wouldn't do this in this case for the reason Simon mentioned.
How many vender-common do we have and is it worth supporting #include <board-common/...>?
On 11/05/2015 10:50 PM, Masahiro Yamada wrote:
2015-11-06 12:30 GMT+09:00 Nishanth Menon nm@ti.com:
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote:
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Hmmm... Are folks ok if I create a softlink?
Or, you can maybe add the following into board/ti/am57xx/Makefile.
subdir-ccflags-y := -I$(src)/../common
then, you can use #include <xyz.h> from your board/ti/am57xx/board.c
I could, OR i could even do ../common/xyz.h (which is what current board files do)
But, I personally wouldn't do this in this case for the reason Simon mentioned.
I agree as well. but the files are built without explicit board level Makefile rules, but the root Makefile(which makes this happen) does not ensure the headers are made available - that sounds contradictory.
How many vender-common do we have and is it worth supporting #include <board-common/...>?
Surprisingly larger set that what I expected: $ git branch -v|grep "^*" * master c3c016cf7536 sf: Add SPI NOR protection mechanism $ find board/ -iname "common"|wc -l 19 $ git grep "#include "../common" board/|wc -l 141
On 11:10-20151106, Nishanth Menon wrote:
On 11/05/2015 10:50 PM, Masahiro Yamada wrote:
2015-11-06 12:30 GMT+09:00 Nishanth Menon nm@ti.com:
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote:
On 11/05/2015 01:28 AM, Nishanth Menon wrote:
When the vendor common libraries exists, then board should be able to reference headers located there, rather than having to do weird logic such as '#include "../common/xyz.h"'.
Signed-off-by: Nishanth Menon nm@ti.com
Makefile | 1 + board/ti/am57xx/board.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..75d5ea802dfd 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Hmmm... Are folks ok if I create a softlink?
Or, you can maybe add the following into board/ti/am57xx/Makefile.
subdir-ccflags-y := -I$(src)/../common
then, you can use #include <xyz.h> from your board/ti/am57xx/board.c
I could, OR i could even do ../common/xyz.h (which is what current board files do)
But, I personally wouldn't do this in this case for the reason Simon mentioned.
I agree as well. but the files are built without explicit board level Makefile rules, but the root Makefile(which makes this happen) does not ensure the headers are made available - that sounds contradictory.
How many vender-common do we have and is it worth supporting #include <board-common/...>?
Surprisingly larger set that what I expected: $ git branch -v|grep "^*"
- master c3c016cf7536 sf: Add SPI NOR protection mechanism
$ find board/ -iname "common"|wc -l 19 $ git grep "#include "../common" board/|wc -l 141
Illustration Purposes only: example of how a #include <board-common/xyz.h" could be done - is this what folks want me to do? diff --git a/Kconfig b/Kconfig index 821b464db207..6e825be0545e 100644 --- a/Kconfig +++ b/Kconfig @@ -224,6 +224,8 @@ endmenu # Boot images
source "common/Kconfig"
+source "board/Kconfig" + source "dts/Kconfig"
source "net/Kconfig" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0d756cbc55a2..62c9b90eac79 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -356,6 +356,7 @@ config TARGET_AM335X_EVM select DM select DM_SERIAL select DM_GPIO + select CREATE_BOARD_SYMLINK
config TARGET_AM335X_SL50 bool "Support am335x_sl50" diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf index d668982cc1dd..3f9b969c2271 100644 --- a/scripts/Makefile.autoconf +++ b/scripts/Makefile.autoconf @@ -125,6 +125,23 @@ else ln -fsn $$dest arch/$(ARCH)/include/asm/arch endif endif +ifdef CONFIG_CREATE_BOARD_SYMLINK +ifneq ($(KBUILD_SRC),) + if [ -d $(KBUILD_SRC)/board/$(VENDOR)/common/include ]; then \ + dest=board/$(VENDOR)/common/include; \ + else \ + dest=board/$(VENDOR)/common; \ + fi; \ + ln -fsn $(KBUILD_SRC)/$$dest include/board-common +else + if [ -d board/$(VENDOR)/common/include ]; then \ + dest=board/$(VENDOR)/common/include; \ + else \ + dest=board/$(VENDOR)/common; \ + fi; \ + ln -fsn ../$$dest include/board-common +endif +endif
PHONY += FORCE FORCE:
Hi,
On 6 November 2015 at 10:23, Nishanth Menon nm@ti.com wrote:
On 11:10-20151106, Nishanth Menon wrote:
On 11/05/2015 10:50 PM, Masahiro Yamada wrote:
2015-11-06 12:30 GMT+09:00 Nishanth Menon nm@ti.com:
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote:
On 11/05/2015 01:28 AM, Nishanth Menon wrote: > When the vendor common libraries exists, then board should be able to > reference headers located there, rather than having to do weird logic > such as '#include "../common/xyz.h"'. > > Signed-off-by: Nishanth Menon nm@ti.com > --- > > Makefile | 1 + > board/ti/am57xx/board.c | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-)
Arrgh.. Apologies on the diffstat messup, but anyways, the patch does apply, and will wait to repost in case of further comments.
> > diff --git a/Makefile b/Makefile > index 3c21f8ddf9e9..75d5ea802dfd 100644 > --- a/Makefile > +++ b/Makefile > @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) > # U-Boot objects....order is important (i.e. start must be first) > > HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) > +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common) > > libs-y += lib/ > libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/ >
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Hmmm... Are folks ok if I create a softlink?
Or, you can maybe add the following into board/ti/am57xx/Makefile.
subdir-ccflags-y := -I$(src)/../common
then, you can use #include <xyz.h> from your board/ti/am57xx/board.c
I could, OR i could even do ../common/xyz.h (which is what current board files do)
But, I personally wouldn't do this in this case for the reason Simon mentioned.
I agree as well. but the files are built without explicit board level Makefile rules, but the root Makefile(which makes this happen) does not ensure the headers are made available - that sounds contradictory.
How many vender-common do we have and is it worth supporting #include <board-common/...>?
Surprisingly larger set that what I expected: $ git branch -v|grep "^*"
- master c3c016cf7536 sf: Add SPI NOR protection mechanism
$ find board/ -iname "common"|wc -l 19 $ git grep "#include "../common" board/|wc -l 141
Illustration Purposes only: example of how a #include <board-common/xyz.h" could be done - is this what folks want me to do? diff --git a/Kconfig b/Kconfig index 821b464db207..6e825be0545e 100644 --- a/Kconfig +++ b/Kconfig @@ -224,6 +224,8 @@ endmenu # Boot images
source "common/Kconfig"
+source "board/Kconfig"
source "dts/Kconfig"
source "net/Kconfig" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0d756cbc55a2..62c9b90eac79 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -356,6 +356,7 @@ config TARGET_AM335X_EVM select DM select DM_SERIAL select DM_GPIO
select CREATE_BOARD_SYMLINKconfig TARGET_AM335X_SL50 bool "Support am335x_sl50" diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf index d668982cc1dd..3f9b969c2271 100644 --- a/scripts/Makefile.autoconf +++ b/scripts/Makefile.autoconf @@ -125,6 +125,23 @@ else ln -fsn $$dest arch/$(ARCH)/include/asm/arch endif endif +ifdef CONFIG_CREATE_BOARD_SYMLINK +ifneq ($(KBUILD_SRC),)
if [ -d $(KBUILD_SRC)/board/$(VENDOR)/common/include ]; then \dest=board/$(VENDOR)/common/include; \else \dest=board/$(VENDOR)/common; \fi; \ln -fsn $(KBUILD_SRC)/$$dest include/board-common+else
if [ -d board/$(VENDOR)/common/include ]; then \dest=board/$(VENDOR)/common/include; \else \dest=board/$(VENDOR)/common; \fi; \ln -fsn ../$$dest include/board-common+endif +endif
PHONY += FORCE FORCE: --
It looks reasonable to me. Tom and Masahiro may have opinions on this too.
Regards, Simon
On Fri, Nov 06, 2015 at 03:58:17PM -0800, Simon Glass wrote:
Hi,
On 6 November 2015 at 10:23, Nishanth Menon nm@ti.com wrote:
On 11:10-20151106, Nishanth Menon wrote:
On 11/05/2015 10:50 PM, Masahiro Yamada wrote:
2015-11-06 12:30 GMT+09:00 Nishanth Menon nm@ti.com:
On Thu, Nov 5, 2015 at 6:15 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 5 November 2015 at 00:32, Nishanth Menon nm@ti.com wrote: > On 11/05/2015 01:28 AM, Nishanth Menon wrote: >> When the vendor common libraries exists, then board should be able to >> reference headers located there, rather than having to do weird logic >> such as '#include "../common/xyz.h"'. >> >> Signed-off-by: Nishanth Menon nm@ti.com >> --- >> >> Makefile | 1 + >> board/ti/am57xx/board.c | 2 +- >> 2 files changed, 2 insertions(+), 1 deletion(-) > > Arrgh.. Apologies on the diffstat messup, but anyways, the patch does > apply, and will wait to repost in case of further comments. > >> >> diff --git a/Makefile b/Makefile >> index 3c21f8ddf9e9..75d5ea802dfd 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) >> # U-Boot objects....order is important (i.e. start must be first) >> >> HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) >> +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common) >> >> libs-y += lib/ >> libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/ >> >
I suppose this is OK. But it might be hard to figure out where a header file is coming from. I wonder if we could make it support:
#include <board-common/...>
and it would find the file?
Hmmm... Are folks ok if I create a softlink?
Or, you can maybe add the following into board/ti/am57xx/Makefile.
subdir-ccflags-y := -I$(src)/../common
then, you can use #include <xyz.h> from your board/ti/am57xx/board.c
I could, OR i could even do ../common/xyz.h (which is what current board files do)
But, I personally wouldn't do this in this case for the reason Simon mentioned.
I agree as well. but the files are built without explicit board level Makefile rules, but the root Makefile(which makes this happen) does not ensure the headers are made available - that sounds contradictory.
How many vender-common do we have and is it worth supporting #include <board-common/...>?
Surprisingly larger set that what I expected: $ git branch -v|grep "^*"
- master c3c016cf7536 sf: Add SPI NOR protection mechanism
$ find board/ -iname "common"|wc -l 19 $ git grep "#include "../common" board/|wc -l 141
Illustration Purposes only: example of how a #include <board-common/xyz.h" could be done - is this what folks want me to do? diff --git a/Kconfig b/Kconfig index 821b464db207..6e825be0545e 100644 --- a/Kconfig +++ b/Kconfig @@ -224,6 +224,8 @@ endmenu # Boot images
source "common/Kconfig"
+source "board/Kconfig"
source "dts/Kconfig"
source "net/Kconfig" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0d756cbc55a2..62c9b90eac79 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -356,6 +356,7 @@ config TARGET_AM335X_EVM select DM select DM_SERIAL select DM_GPIO
select CREATE_BOARD_SYMLINKconfig TARGET_AM335X_SL50 bool "Support am335x_sl50" diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf index d668982cc1dd..3f9b969c2271 100644 --- a/scripts/Makefile.autoconf +++ b/scripts/Makefile.autoconf @@ -125,6 +125,23 @@ else ln -fsn $$dest arch/$(ARCH)/include/asm/arch endif endif +ifdef CONFIG_CREATE_BOARD_SYMLINK +ifneq ($(KBUILD_SRC),)
if [ -d $(KBUILD_SRC)/board/$(VENDOR)/common/include ]; then \dest=board/$(VENDOR)/common/include; \else \dest=board/$(VENDOR)/common; \fi; \ln -fsn $(KBUILD_SRC)/$$dest include/board-common+else
if [ -d board/$(VENDOR)/common/include ]; then \dest=board/$(VENDOR)/common/include; \else \dest=board/$(VENDOR)/common; \fi; \ln -fsn ../$$dest include/board-common+endif +endif
PHONY += FORCE FORCE: --
It looks reasonable to me. Tom and Masahiro may have opinions on this too.
Conceptually fine with me. Do we really need a config option for it tho?
On Sat, Nov 7, 2015 at 8:18 PM, Tom Rini trini@konsulko.com wrote:
Conceptually fine with me. Do we really need a config option for it tho?
I was following the lines of CONFIG_CREATE_ARCH_SYMLINK here. Is there some reason why you'd not want it so?
Regards, Nishanth Menon
On Sun, Nov 08, 2015 at 09:56:18AM -0600, menon.nishanth@gmail.com wrote:
On Sat, Nov 7, 2015 at 8:18 PM, Tom Rini trini@konsulko.com wrote:
Conceptually fine with me. Do we really need a config option for it tho?
I was following the lines of CONFIG_CREATE_ARCH_SYMLINK here. Is there some reason why you'd not want it so?
Masahiro?
2015-11-09 1:38 GMT+09:00 Tom Rini trini@konsulko.com:
On Sun, Nov 08, 2015 at 09:56:18AM -0600, menon.nishanth@gmail.com wrote:
On Sat, Nov 7, 2015 at 8:18 PM, Tom Rini trini@konsulko.com wrote:
Conceptually fine with me. Do we really need a config option for it tho?
I was following the lines of CONFIG_CREATE_ARCH_SYMLINK here. Is there some reason why you'd not want it so?
Masahiro?
Is this an improvement?
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
On 11/09/2015 10:03 AM, Masahiro Yamada wrote:
2015-11-09 1:38 GMT+09:00 Tom Rini trini@konsulko.com:
On Sun, Nov 08, 2015 at 09:56:18AM -0600, menon.nishanth@gmail.com wrote:
On Sat, Nov 7, 2015 at 8:18 PM, Tom Rini trini@konsulko.com wrote:
Conceptually fine with me. Do we really need a config option for it tho?
I was following the lines of CONFIG_CREATE_ARCH_SYMLINK here. Is there some reason why you'd not want it so?
Masahiro?
Is this an improvement?
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
OK. what do we do? option 1: #include "..common/xyz.h" 141 something usage in board files do this for now..
option 2: -I...common (auto generated - original patch) #include "xyz.h" we dont like that since it does not tell us that xyz.h is a board-common header.
option 3: #include <board-common/xyz.h>
this needs a soft link which we dont like either.
are there any other ways to do this?
Hi Masahiro,
On 9 November 2015 at 09:37, Nishanth Menon nm@ti.com wrote:
On 11/09/2015 10:03 AM, Masahiro Yamada wrote:
2015-11-09 1:38 GMT+09:00 Tom Rini trini@konsulko.com:
On Sun, Nov 08, 2015 at 09:56:18AM -0600, menon.nishanth@gmail.com wrote:
On Sat, Nov 7, 2015 at 8:18 PM, Tom Rini trini@konsulko.com wrote:
Conceptually fine with me. Do we really need a config option for it tho?
I was following the lines of CONFIG_CREATE_ARCH_SYMLINK here. Is there some reason why you'd not want it so?
Masahiro?
Is this an improvement?
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
OK. what do we do? option 1: #include "..common/xyz.h" 141 something usage in board files do this for now..
option 2: -I...common (auto generated - original patch) #include "xyz.h" we dont like that since it does not tell us that xyz.h is a board-common header.
option 3: #include <board-common/xyz.h>
this needs a soft link which we dont like either.
Well, I like it :-)
are there any other ways to do this?
-- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Regards, Simon
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org:
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK. what do we do? option 1: #include "..common/xyz.h" 141 something usage in board files do this for now..
option 2: -I...common (auto generated - original patch) #include "xyz.h" we dont like that since it does not tell us that xyz.h is a board-common header.
option 3: #include <board-common/xyz.h>
this needs a soft link which we dont like either.
Well, I like it :-)
are there any other ways to do this?
-- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 12:25-20151110, Masahiro Yamada wrote:
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org:
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
On 11/10/2015 08:55 AM, Nishanth Menon wrote:
On 12:25-20151110, Masahiro Yamada wrote:
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org:
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
Spin off from option 4 is option 5 -> where we dont have the Makefile change. the board includes are located in include/board-common/$(VENDOR)/ directory.
Usage will be:
#include <board-common/$(VENDOR)/xyz.h>
Almost meets Simon's needs(identifiable as board common header) and I think matches what Masahiro-san wants as well(no symlinks).
OK, i am out of ideas at least for now... Any other suggestions / opinions?
Hi,
On 10 November 2015 at 08:34, Nishanth Menon nm@ti.com wrote:
On 11/10/2015 08:55 AM, Nishanth Menon wrote:
On 12:25-20151110, Masahiro Yamada wrote:
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org:
I am unhappy because I was hoping we could stop creating symbolic links during building in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
Spin off from option 4 is option 5 -> where we dont have the Makefile change. the board includes are located in include/board-common/$(VENDOR)/ directory.
Usage will be:
#include <board-common/$(VENDOR)/xyz.h>
Almost meets Simon's needs(identifiable as board common header) and I think matches what Masahiro-san wants as well(no symlinks).
OK, i am out of ideas at least for now... Any other suggestions / opinions?
If we don't want a symlink then option 5 seems good to me. Thanks very much for looking into this in so much detail, Nishanth.
Thoughts - Masahiro? Tom?
Regards, Simon
On Thu, Nov 12, 2015 at 09:16:00AM -0700, Simon Glass wrote:
Hi,
On 10 November 2015 at 08:34, Nishanth Menon nm@ti.com wrote:
On 11/10/2015 08:55 AM, Nishanth Menon wrote:
On 12:25-20151110, Masahiro Yamada wrote:
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org:
> I am unhappy because I was hoping > we could stop creating symbolic links during building > in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
Spin off from option 4 is option 5 -> where we dont have the Makefile change. the board includes are located in include/board-common/$(VENDOR)/ directory.
Usage will be:
#include <board-common/$(VENDOR)/xyz.h>
Almost meets Simon's needs(identifiable as board common header) and I think matches what Masahiro-san wants as well(no symlinks).
OK, i am out of ideas at least for now... Any other suggestions / opinions?
If we don't want a symlink then option 5 seems good to me. Thanks very much for looking into this in so much detail, Nishanth.
Thoughts - Masahiro? Tom?
No symlink should mean Masahiro is happy, so if you're fine with #5 then that works for me too, thanks!
On 11/12/2015 10:22 AM, Tom Rini wrote:
On Thu, Nov 12, 2015 at 09:16:00AM -0700, Simon Glass wrote:
Hi,
On 10 November 2015 at 08:34, Nishanth Menon nm@ti.com wrote:
On 11/10/2015 08:55 AM, Nishanth Menon wrote:
On 12:25-20151110, Masahiro Yamada wrote:
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org:
>> I am unhappy because I was hoping >> we could stop creating symbolic links during building >> in a long run.
But how? I don't see that it is possible if we want to have a sensible prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
Spin off from option 4 is option 5 -> where we dont have the Makefile change. the board includes are located in include/board-common/$(VENDOR)/ directory.
Usage will be:
#include <board-common/$(VENDOR)/xyz.h>
Almost meets Simon's needs(identifiable as board common header) and I think matches what Masahiro-san wants as well(no symlinks).
OK, i am out of ideas at least for now... Any other suggestions / opinions?
If we don't want a symlink then option 5 seems good to me. Thanks very much for looking into this in so much detail, Nishanth.
Thoughts - Masahiro? Tom?
No symlink should mean Masahiro is happy, so if you're fine with #5 then that works for me too, thanks!
I just have yet another option 6 variation -> looking at the mach strategy:
UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common/include)
vendors should create common headers in board/$(VENDOR)/include/board-common/xyz.h
the users then can do: #include <board-common/xyz.h>
How does that sound? ofcourse, similar to mach, it requires some discipline..
Hi Nishanth,
On 12 November 2015 at 09:45, Nishanth Menon nm@ti.com wrote:
On 11/12/2015 10:22 AM, Tom Rini wrote:
On Thu, Nov 12, 2015 at 09:16:00AM -0700, Simon Glass wrote:
Hi,
On 10 November 2015 at 08:34, Nishanth Menon nm@ti.com wrote:
On 11/10/2015 08:55 AM, Nishanth Menon wrote:
On 12:25-20151110, Masahiro Yamada wrote:
2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org: >>> I am unhappy because I was hoping >>> we could stop creating symbolic links during building >>> in a long run. > > But how? I don't see that it is possible if we want to have a sensible > prefix for each include.
[step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach
[step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h>
[step 3] Drop CONFIG_CREATE_ARCH_SYMLINK
For example, mach-uniphier finished [1] and [2], so it does not require the symbolic link. (several ARM SoCs finished [1])
I think this is the way ARM should do, at least.
The topic of debate is PowerPC. Should we introduce mach-<soc> directories or not?
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
Spin off from option 4 is option 5 -> where we dont have the Makefile change. the board includes are located in include/board-common/$(VENDOR)/ directory.
Usage will be:
#include <board-common/$(VENDOR)/xyz.h>
Almost meets Simon's needs(identifiable as board common header) and I think matches what Masahiro-san wants as well(no symlinks).
OK, i am out of ideas at least for now... Any other suggestions / opinions?
If we don't want a symlink then option 5 seems good to me. Thanks very much for looking into this in so much detail, Nishanth.
Thoughts - Masahiro? Tom?
No symlink should mean Masahiro is happy, so if you're fine with #5 then that works for me too, thanks!
I just have yet another option 6 variation -> looking at the mach strategy:
UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common/include)
vendors should create common headers in board/$(VENDOR)/include/board-common/xyz.h
the users then can do: #include <board-common/xyz.h>
How does that sound? ofcourse, similar to mach, it requires some discipline..
Looks good, and it's nice that the files are in board/
Regards, Simon
On Thu, Nov 12, 2015 at 09:56:26AM -0700, Simon Glass wrote:
Hi Nishanth,
On 12 November 2015 at 09:45, Nishanth Menon nm@ti.com wrote:
On 11/12/2015 10:22 AM, Tom Rini wrote:
On Thu, Nov 12, 2015 at 09:16:00AM -0700, Simon Glass wrote:
Hi,
On 10 November 2015 at 08:34, Nishanth Menon nm@ti.com wrote:
On 11/10/2015 08:55 AM, Nishanth Menon wrote:
On 12:25-20151110, Masahiro Yamada wrote: > 2015-11-10 5:24 GMT+09:00 Simon Glass sjg@chromium.org: >>>> I am unhappy because I was hoping >>>> we could stop creating symbolic links during building >>>> in a long run. >> >> But how? I don't see that it is possible if we want to have a sensible >> prefix for each include. > > > [step 1] move SoC-specific headers to arch/<arch>/mach-<soc>/include/mach > > [step 2] change #include <asm/arch/foo.h> to #include <mach/foo.h> > > [step 3] Drop CONFIG_CREATE_ARCH_SYMLINK > > > For example, mach-uniphier finished [1] and [2], > so it does not require the symbolic link. > (several ARM SoCs finished [1]) > > > I think this is the way ARM should do, at least. > > The topic of debate is PowerPC. Should we introduce mach-<soc> > directories or not? >
OK: Option 4:
How about this guys? include/board-common is an actual directory and instead of headers being located in board/$(VENDOR)/common or board/$(VENDOR)/common/include, we move the common headers to include/board/$(VENDOR)/ Directory. This will make the usage as follows:
#include <$(VENDOR)/xyz.h>
I know this does not exactly meet Simon's suggestion here of being identifiably board-common/xyz.h -> but at least knowing the prefix as vendor name implies a board common header.
diff --git a/Makefile b/Makefile index 3c21f8ddf9e9..2bd684199512 100644 --- a/Makefile +++ b/Makefile @@ -620,6 +620,7 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags) # U-Boot objects....order is important (i.e. start must be first)
HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n) +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/include/board-common)
libs-y += lib/ libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
How does this sound?
Spin off from option 4 is option 5 -> where we dont have the Makefile change. the board includes are located in include/board-common/$(VENDOR)/ directory.
Usage will be:
#include <board-common/$(VENDOR)/xyz.h>
Almost meets Simon's needs(identifiable as board common header) and I think matches what Masahiro-san wants as well(no symlinks).
OK, i am out of ideas at least for now... Any other suggestions / opinions?
If we don't want a symlink then option 5 seems good to me. Thanks very much for looking into this in so much detail, Nishanth.
Thoughts - Masahiro? Tom?
No symlink should mean Masahiro is happy, so if you're fine with #5 then that works for me too, thanks!
I just have yet another option 6 variation -> looking at the mach strategy:
UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), -I$(srctree)/board/$(VENDOR)/common/include)
vendors should create common headers in board/$(VENDOR)/include/board-common/xyz.h
the users then can do: #include <board-common/xyz.h>
How does that sound? ofcourse, similar to mach, it requires some discipline..
Looks good, and it's nice that the files are in board/
#6 it is, thanks again Nishanth!
participants (5)
-
Masahiro Yamada -
menon.nishanth＠gmail.com -
Nishanth Menon -
Simon Glass -
Tom Rini