* How to extend SRC_URI_append? @ 2010-09-03 11:12 Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 14:44 ` Chris Larson 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 2 replies; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 11:12 UTC (permalink / raw) To: openembedded-devel Hi, I'm currently working on the adding of a sub SH arch the st40 for this I've define the SOC_FAMILY as SOC_FAMILY="st40" but now I want to apply some patch to gcc, binutils and others via SRC_URI_append_st40 or SRC_URI_append_sh_st40 how can i do it? Best Regards, J. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 11:12 How to extend SRC_URI_append? Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 14:44 ` Chris Larson 2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD 1 sibling, 1 reply; 24+ messages in thread From: Chris Larson @ 2010-09-03 14:44 UTC (permalink / raw) To: openembedded-devel The append syntax you're referring to uses OVERRIDES. FOO_somevalue replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is added to FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in overrides at this time. On Fri, Sep 3, 2010 at 4:12 AM, Jean-Christophe PLAGNIOL-VILLARD < plagnioj@jcrosoft.com> wrote: > Hi, > > I'm currently working on the adding of a sub SH arch the st40 > > for this I've define the SOC_FAMILY as SOC_FAMILY="st40" > > but now I want to apply some patch to gcc, binutils and others > > via SRC_URI_append_st40 or SRC_URI_append_sh_st40 > > how can i do it? > > Best Regards, > J. > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 14:44 ` Chris Larson @ 2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 1 reply; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 16:47 UTC (permalink / raw) To: openembedded-devel On 07:44 Fri 03 Sep , Chris Larson wrote: > The append syntax you're referring to uses OVERRIDES. FOO_somevalue > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is added to > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in overrides > at this time. how can I extend it? Best Regards, J. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 20:34 ` Maupin, Chase 0 siblings, 1 reply; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 16:59 UTC (permalink / raw) To: openembedded-devel On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote: > On 07:44 Fri 03 Sep , Chris Larson wrote: > > The append syntax you're referring to uses OVERRIDES. FOO_somevalue > > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is added to > > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in overrides > > at this time. > how can I extend it? is this ok? diff --git a/conf/bitbake.conf b/conf/bitbake.conf index 677c76a..ecdf245 100644 --- a/conf/bitbake.conf +++ b/conf/bitbake.conf @@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS" # # This works for functions as well, they are really just environment variables. # Default OVERRIDES to make compilation fail fast in case of build system misconfiguration. -OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}" +OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TARGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}" # Alternative OVERRIDES definition without "fail fast", usually only for native building and Scratchbox toolchains. -#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}" +#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TARGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}" ################################################################## # Include the rest of the config files. Best Regards, J. ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 20:34 ` Maupin, Chase 2010-09-03 21:45 ` Khem Raj ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Maupin, Chase @ 2010-09-03 20:34 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org > -----Original Message----- > From: openembedded-devel-bounces@lists.openembedded.org > [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of > Jean-Christophe PLAGNIOL-VILLARD > Sent: Friday, September 03, 2010 11:59 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] How to extend SRC_URI_append? > > On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 07:44 Fri 03 Sep , Chris Larson wrote: > > > The append syntax you're referring to uses OVERRIDES. FOO_somevalue > > > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is > added to > > > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in > overrides > > > at this time. > > how can I extend it? > is this ok? > > diff --git a/conf/bitbake.conf b/conf/bitbake.conf > index 677c76a..ecdf245 100644 > --- a/conf/bitbake.conf > +++ b/conf/bitbake.conf > @@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS" > # > # This works for functions as well, they are really just environment > variables. > # Default OVERRIDES to make compilation fail fast in case of build system > misconfiguration. > -OVERRIDES = > "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build- > ${BUILD_OS}:fail-fast:pn-${PN}" > +OVERRIDES = > "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA > RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}" > # Alternative OVERRIDES definition without "fail fast", usually only for > native building and Scratchbox toolchains. > -#OVERRIDES = > "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build- > ${BUILD_OS}:pn-${PN}" > +#OVERRIDES = > "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA > RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}" > > ################################################################## > # Include the rest of the config files. > > Best Regards, > J. Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family? As for adding this to bitbake.conf I guess I wouldn't object, but I don't know that this is something everyone would want. Instead you could put this in your distro's conf file (like angstrom does) or in your local.conf file. The distro/include/angstrom.inc file sets: OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}" I use SOC_FAMILY overrides in my work. Just my two cents > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 20:34 ` Maupin, Chase @ 2010-09-03 21:45 ` Khem Raj 2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD 2 siblings, 0 replies; 24+ messages in thread From: Khem Raj @ 2010-09-03 21:45 UTC (permalink / raw) To: openembedded-devel On Fri, Sep 3, 2010 at 1:34 PM, Maupin, Chase <chase.maupin@ti.com> wrote: >> -----Original Message----- >> From: openembedded-devel-bounces@lists.openembedded.org >> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of >> Jean-Christophe PLAGNIOL-VILLARD >> Sent: Friday, September 03, 2010 11:59 AM >> To: openembedded-devel@lists.openembedded.org >> Subject: Re: [oe] How to extend SRC_URI_append? >> >> On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote: >> > On 07:44 Fri 03 Sep , Chris Larson wrote: >> > > The append syntax you're referring to uses OVERRIDES. FOO_somevalue >> > > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is >> added to >> > > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in >> overrides >> > > at this time. >> > how can I extend it? >> is this ok? >> >> diff --git a/conf/bitbake.conf b/conf/bitbake.conf >> index 677c76a..ecdf245 100644 >> --- a/conf/bitbake.conf >> +++ b/conf/bitbake.conf >> @@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS" >> # >> # This works for functions as well, they are really just environment >> variables. >> # Default OVERRIDES to make compilation fail fast in case of build system >> misconfiguration. >> -OVERRIDES = >> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build- >> ${BUILD_OS}:fail-fast:pn-${PN}" >> +OVERRIDES = >> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA >> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}" >> # Alternative OVERRIDES definition without "fail fast", usually only for >> native building and Scratchbox toolchains. >> -#OVERRIDES = >> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build- >> ${BUILD_OS}:pn-${PN}" >> +#OVERRIDES = >> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA >> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}" >> >> ################################################################## >> # Include the rest of the config files. >> >> Best Regards, >> J. > > Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family? > > As for adding this to bitbake.conf I guess I wouldn't object, but I don't know that this is something everyone would want. Instead you could put this in your distro's conf file (like angstrom does) or in your local.conf file. > > The distro/include/angstrom.inc file sets: > > OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}" second option is better. > > I use SOC_FAMILY overrides in my work. > > Just my two cents >> >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 20:34 ` Maupin, Chase 2010-09-03 21:45 ` Khem Raj @ 2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD 2 siblings, 0 replies; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 3:17 UTC (permalink / raw) To: openembedded-devel > > Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family? yes I've as I've the same soc family on 2 arch with 2 patch series I'm preparing it and will send soon I hope Best Regards J. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append? 2010-09-03 20:34 ` Maupin, Chase 2010-09-03 21:45 ` Khem Raj 2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD 2 siblings, 0 replies; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 11:20 UTC (permalink / raw) To: openembedded-devel > > > > ################################################################## > > # Include the rest of the config files. > > > > Best Regards, > > J. > > Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family? > > As for adding this to bitbake.conf I guess I wouldn't object, but I don't know that this is something everyone would want. Instead you could put this in your distro's conf file (like angstrom does) or in your local.conf file. I disagree as example I've to apply patch to gcc, binutils or directfb and other componets so it's absolutelt not distro specific but SoC and hardware specific so if we make it distros specific we will have to add it to all of them to support this familly of SoC Best Regards, J. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-03 11:12 How to extend SRC_URI_append? Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 14:44 ` Chris Larson @ 2010-09-04 3:14 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 7:45 ` Frans Meulenbroeks ` (3 more replies) 1 sibling, 4 replies; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 3:14 UTC (permalink / raw) To: openembedded-devel add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY} Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> --- classes/base.bbclass | 4 ++-- conf/bitbake.conf | 6 ++++-- conf/distro/include/angstrom.inc | 6 ++---- conf/machine/include/dm355.inc | 2 +- conf/machine/include/dm365.inc | 2 +- conf/machine/include/dm6446.inc | 2 +- conf/machine/include/dm6467.inc | 2 +- conf/machine/include/omap3.inc | 2 +- conf/machine/include/omapl137.inc | 2 +- conf/machine/include/omapl138.inc | 2 +- recipes/ti/ti-codec-engine.inc | 2 +- recipes/ti/ti-dsplink.inc | 2 +- recipes/ti/ti-linuxutils.inc | 4 ++-- recipes/ti/ti-local-power-manager.inc | 2 +- 14 files changed, 20 insertions(+), 20 deletions(-) diff --git a/classes/base.bbclass b/classes/base.bbclass index 299e875..0085655 100644 --- a/classes/base.bbclass +++ b/classes/base.bbclass @@ -336,8 +336,8 @@ python () { import re this_machine = bb.data.getVar('MACHINE', d, 1) if this_machine and not re.match(need_machine, this_machine): - this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1) - if this_soc_family and not re.match(need_machine, this_soc_family): + this_target_soc_family = bb.data.getVar('TARGET_SOC_FAMILY', d, 1) + if this_target_soc_family and not re.match(need_machine, this_target_soc_family): raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine) need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1) diff --git a/conf/bitbake.conf b/conf/bitbake.conf index 677c76a..672d8df 100644 --- a/conf/bitbake.conf +++ b/conf/bitbake.conf @@ -113,6 +113,8 @@ TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS' TARGET_PREFIX = "${TARGET_SYS}-" TARGET_CC_ARCH = "" TARGET_EXEEXT = "" +TARGET_SOC_FAMILY ?= "Unknown" + SDK_ARCH ?= "${BUILD_ARCH}" SDK_OS ?= "${BUILD_OS}" @@ -677,9 +679,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS" # # This works for functions as well, they are really just environment variables. # Default OVERRIDES to make compilation fail fast in case of build system misconfiguration. -OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}" +OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${TARGET_SOC_FAMILY}:${TARGET_ARCH}_${TARGET_SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}" # Alternative OVERRIDES definition without "fail fast", usually only for native building and Scratchbox toolchains. -#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}" +#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${TARGET_SOC_FAMILY}:${TARGET_ARCH}_${TARGET_SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}" ################################################################## # Include the rest of the config files. diff --git a/conf/distro/include/angstrom.inc b/conf/distro/include/angstrom.inc index 8983c86..ae6781d 100644 --- a/conf/distro/include/angstrom.inc +++ b/conf/distro/include/angstrom.inc @@ -11,10 +11,8 @@ BUILDNAME = "Angstrom ${DISTRO_VERSION}" TARGET_VENDOR = "-angstrom" -SOC_FAMILY ?= "Unknown" - -# Add FEED_ARCH and SOC_FAMILY to overrides -OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}" +# Add FEED_ARCH to overrides +OVERRIDES .= ":${FEED_ARCH}" # Put links to sources in deploy/sources to make it easier for people to be GPL compliant INHERIT += "src_distribute_local" diff --git a/conf/machine/include/dm355.inc b/conf/machine/include/dm355.inc index d666d5e..19556691 100644 --- a/conf/machine/include/dm355.inc +++ b/conf/machine/include/dm355.inc @@ -1,2 +1,2 @@ -SOC_FAMILY = "dm355" +TARGET_SOC_FAMILY = "dm355" diff --git a/conf/machine/include/dm365.inc b/conf/machine/include/dm365.inc index b974f2c..6793c74 100644 --- a/conf/machine/include/dm365.inc +++ b/conf/machine/include/dm365.inc @@ -1,2 +1,2 @@ -SOC_FAMILY = "dm365" +TARGET_SOC_FAMILY = "dm365" diff --git a/conf/machine/include/dm6446.inc b/conf/machine/include/dm6446.inc index 827b375..5e2f16c 100644 --- a/conf/machine/include/dm6446.inc +++ b/conf/machine/include/dm6446.inc @@ -1,2 +1,2 @@ -SOC_FAMILY = "dm6446" +TARGET_SOC_FAMILY = "dm6446" diff --git a/conf/machine/include/dm6467.inc b/conf/machine/include/dm6467.inc index 5200f85..b5ed729 100644 --- a/conf/machine/include/dm6467.inc +++ b/conf/machine/include/dm6467.inc @@ -1 +1 @@ -SOC_FAMILY = "dm6467" +TARGET_SOC_FAMILY = "dm6467" diff --git a/conf/machine/include/omap3.inc b/conf/machine/include/omap3.inc index 1052296..d1ffcad 100644 --- a/conf/machine/include/omap3.inc +++ b/conf/machine/include/omap3.inc @@ -1,4 +1,4 @@ -SOC_FAMILY = "omap3" +TARGET_SOC_FAMILY = "omap3" require conf/machine/include/tune-cortexa8.inc PREFERRED_PROVIDER_virtual/kernel = "linux-omap" diff --git a/conf/machine/include/omapl137.inc b/conf/machine/include/omapl137.inc index cd84594..7187572 100644 --- a/conf/machine/include/omapl137.inc +++ b/conf/machine/include/omapl137.inc @@ -1 +1 @@ -SOC_FAMILY = "omapl137" +TARGET_SOC_FAMILY = "omapl137" diff --git a/conf/machine/include/omapl138.inc b/conf/machine/include/omapl138.inc index 4c22275..887aabe 100644 --- a/conf/machine/include/omapl138.inc +++ b/conf/machine/include/omapl138.inc @@ -1 +1 @@ -SOC_FAMILY = "omapl138" +TARGET_SOC_FAMILY = "omapl138" diff --git a/recipes/ti/ti-codec-engine.inc b/recipes/ti/ti-codec-engine.inc index 1b89ea7..56347b0 100644 --- a/recipes/ti/ti-codec-engine.inc +++ b/recipes/ti/ti-codec-engine.inc @@ -25,7 +25,7 @@ DEPENDS_append_omap3 = " ti-dspbios ti-dsplink ti-local-power-manager ti-cgt6x t DEPENDS_append_omapl137 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld" DEPENDS_append_omapl138 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld" -# SOC_FAMILY configuration +# TARGET_SOC_FAMILY configuration # Define DEVICES variable CEEXAMPLESDEVICES_dm6446 = "DM6446" diff --git a/recipes/ti/ti-dsplink.inc b/recipes/ti/ti-dsplink.inc index 388d057..2fb7079 100644 --- a/recipes/ti/ti-dsplink.inc +++ b/recipes/ti/ti-dsplink.inc @@ -28,7 +28,7 @@ SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/${PV_DL_PATH}/dsplink_l DEPENDS = "ti-dspbios ti-xdctools ti-cgt6x" DEPENDS += "virtual/kernel perl-native" -# SOC_FAMILY configuration +# TARGET_SOC_FAMILY configuration DSPLINKPLATFORM_dm6446 = "DAVINCI" DSPLINKPLATFORM_dm6467 = "DAVINCIHD" diff --git a/recipes/ti/ti-linuxutils.inc b/recipes/ti/ti-linuxutils.inc index 073416a..c650044 100644 --- a/recipes/ti/ti-linuxutils.inc +++ b/recipes/ti/ti-linuxutils.inc @@ -18,7 +18,7 @@ inherit module do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS - case ${SOC_FAMILY} in + case ${TARGET_SOC_FAMILY} in dm365) modules="cmem edma irq";; omap3) @@ -53,7 +53,7 @@ do_install () { EXEC_DIR="${D}${installdir}/ti-linuxutils-app/cmem-app" \ install # Install EDMA - if [ ${SOC_FAMILY} == "dm365" ] ; then + if [ ${TARGET_SOC_FAMILY} == "dm365" ] ; then cd ${S}/packages/ti/sdo/linuxutils/edma/apps make \ LINUXKERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" \ diff --git a/recipes/ti/ti-local-power-manager.inc b/recipes/ti/ti-local-power-manager.inc index a0e3bfd..31f9243 100644 --- a/recipes/ti/ti-local-power-manager.inc +++ b/recipes/ti/ti-local-power-manager.inc @@ -22,7 +22,7 @@ SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/lp DEPENDS = "ti-dsplink ti-xdctools" DEPENDS += "virtual/kernel" -# SOC_FAMILY configuration +# TARGET_SOC_FAMILY configuration LPMDSPPOWERSOC_omap3 = "omap3530" LPMDSPPOWERSOC_dm6446 = "dm6446" -- 1.7.2 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 7:45 ` Frans Meulenbroeks 2010-09-04 8:20 ` Frans Meulenbroeks 2010-09-07 14:43 ` Maupin, Chase ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Frans Meulenbroeks @ 2010-09-04 7:45 UTC (permalink / raw) To: openembedded-devel 2010/9/4 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>: > add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY} > What is the rationale for this? And why not fix the problem there is in base.bbclass as well. Frans. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-04 7:45 ` Frans Meulenbroeks @ 2010-09-04 8:20 ` Frans Meulenbroeks 2010-09-07 14:21 ` Maupin, Chase 0 siblings, 1 reply; 24+ messages in thread From: Frans Meulenbroeks @ 2010-09-04 8:20 UTC (permalink / raw) To: openembedded-devel 2010/9/4 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>: > 2010/9/4 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>: >> add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY} >> > > What is the rationale for this? > And why not fix the problem there is in base.bbclass as well. > > Frans. > Forgot about this, but a variable should go with documentation. This already has been raised with the orginal patch, but was ignored by the submitters. Consider this a NAK. Frans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-04 8:20 ` Frans Meulenbroeks @ 2010-09-07 14:21 ` Maupin, Chase 2010-09-08 5:58 ` Frans Meulenbroeks 0 siblings, 1 reply; 24+ messages in thread From: Maupin, Chase @ 2010-09-07 14:21 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org > -----Original Message----- > From: openembedded-devel-bounces@lists.openembedded.org > [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of > Frans Meulenbroeks > Sent: Saturday, September 04, 2010 3:20 AM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make > it global > > 2010/9/4 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>: > > 2010/9/4 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>: > >> add global OVERRIDES ${TARGET_SOC_FAMILY} and > ${TARGET_ARCH}_${TARGET_SOC_FAMILY} > >> > > > > What is the rationale for this? > > And why not fix the problem there is in base.bbclass as well. > > > > Frans. > > > Forgot about this, but a variable should go with documentation. > This already has been raised with the orginal patch, but was ignored > by the submitters. Frans, Are you counting me as one of the original submitters? I mainly use the SOC_FAMILY, I didn't create it. That being said, if you have a recommended section of the usermanual that this should be documented in I'll try to add something. > > Consider this a NAK. > > Frans > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-07 14:21 ` Maupin, Chase @ 2010-09-08 5:58 ` Frans Meulenbroeks 2010-09-10 18:57 ` Denys Dmytriyenko 0 siblings, 1 reply; 24+ messages in thread From: Frans Meulenbroeks @ 2010-09-08 5:58 UTC (permalink / raw) To: openembedded-devel 2010/9/7 Maupin, Chase <chase.maupin@ti.com>: >> Forgot about this, but a variable should go with documentation. >> This already has been raised with the orginal patch, but was ignored >> by the submitters. > > Frans, Are you counting me as one of the original submitters? I mainly use the SOC_FAMILY, I didn't create it. That being said, if you have a recommended section of the usermanual that this should be documented in I'll try to add something. > Hi Chase, I see you indeed as the submitter. The commit carries your name and there is no reference in the commit message of another author. Wrt the manual: actually I thought we had a section for this, but as it stands i cannot find it. Guess I saw it somewhere else. I'm not really sure where it would fit. I guess there are others who have a better view on the manual and its structure. Frans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-08 5:58 ` Frans Meulenbroeks @ 2010-09-10 18:57 ` Denys Dmytriyenko 2010-09-10 20:32 ` Tom Rini 2010-09-12 7:40 ` Frans Meulenbroeks 0 siblings, 2 replies; 24+ messages in thread From: Denys Dmytriyenko @ 2010-09-10 18:57 UTC (permalink / raw) To: openembedded-devel On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote: > 2010/9/7 Maupin, Chase <chase.maupin@ti.com>: > > >> Forgot about this, but a variable should go with documentation. > >> This already has been raised with the orginal patch, but was ignored > >> by the submitters. > > > > Frans, Are you counting me as one of the original submitters? I mainly > > use the SOC_FAMILY, I didn't create it. That being said, if you have a > > recommended section of the usermanual that this should be documented in > > I'll try to add something. > > Hi Chase, > I see you indeed as the submitter. The commit carries your name and > there is no reference in the commit message of another author. > > Wrt the manual: actually I thought we had a section for this, but as > it stands i cannot find it. Guess I saw it somewhere else. > I'm not really sure where it would fit. I guess there are others who > have a better view on the manual and its structure. Frans, I guess then you haven't read the original discussion closely enough. Chase only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE variable... I keep repeating myself - SOC_FAMILY feature is about a year old. It was introduced as part of a large merge from Arago. Here is the original commit and some description: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816 -- Denys ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-10 18:57 ` Denys Dmytriyenko @ 2010-09-10 20:32 ` Tom Rini 2010-09-10 20:43 ` Denys Dmytriyenko 2010-09-12 7:40 ` Frans Meulenbroeks 1 sibling, 1 reply; 24+ messages in thread From: Tom Rini @ 2010-09-10 20:32 UTC (permalink / raw) To: openembedded-devel Denys Dmytriyenko wrote: > On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote: >> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>: >> >>>> Forgot about this, but a variable should go with documentation. >>>> This already has been raised with the orginal patch, but was ignored >>>> by the submitters. >>> Frans, Are you counting me as one of the original submitters? I mainly >>> use the SOC_FAMILY, I didn't create it. That being said, if you have a >>> recommended section of the usermanual that this should be documented in >>> I'll try to add something. >> Hi Chase, >> I see you indeed as the submitter. The commit carries your name and >> there is no reference in the commit message of another author. >> >> Wrt the manual: actually I thought we had a section for this, but as >> it stands i cannot find it. Guess I saw it somewhere else. >> I'm not really sure where it would fit. I guess there are others who >> have a better view on the manual and its structure. > > Frans, > > I guess then you haven't read the original discussion closely enough. Chase > only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE > variable... I keep repeating myself - SOC_FAMILY feature is about a year old. > It was introduced as part of a large merge from Arago. Here is the original > commit and some description: > > http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816 I suppose you could save Chase some time, Denys, and update the manual instead :) But to me, it's perfectly reasonable for Frans to ask that when someone renames a not previously documented variable to go ahead and document it too (since they must have some knowledge of how it works, and some correct knowledge being written down is better than none). -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-10 20:32 ` Tom Rini @ 2010-09-10 20:43 ` Denys Dmytriyenko 2010-09-11 9:19 ` Frans Meulenbroeks 0 siblings, 1 reply; 24+ messages in thread From: Denys Dmytriyenko @ 2010-09-10 20:43 UTC (permalink / raw) To: openembedded-devel On Fri, Sep 10, 2010 at 01:32:39PM -0700, Tom Rini wrote: > Denys Dmytriyenko wrote: >> On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote: >>> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>: >>> >>>>> Forgot about this, but a variable should go with documentation. >>>>> This already has been raised with the orginal patch, but was ignored >>>>> by the submitters. >>>> Frans, Are you counting me as one of the original submitters? I mainly >>>> use the SOC_FAMILY, I didn't create it. That being said, if you have a >>>> recommended section of the usermanual that this should be documented in >>>> I'll try to add something. >>> Hi Chase, >>> I see you indeed as the submitter. The commit carries your name and >>> there is no reference in the commit message of another author. >>> >>> Wrt the manual: actually I thought we had a section for this, but as >>> it stands i cannot find it. Guess I saw it somewhere else. >>> I'm not really sure where it would fit. I guess there are others who >>> have a better view on the manual and its structure. >> Frans, >> I guess then you haven't read the original discussion closely enough. >> Chase only made a change to add existing SOC_FAMILY override into >> COMPATIBLE_MACHINE variable... I keep repeating myself - SOC_FAMILY >> feature is about a year old. It was introduced as part of a large merge >> from Arago. Here is the original commit and some description: >> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816 > > I suppose you could save Chase some time, Denys, and update the manual > instead :) But to me, it's perfectly reasonable for Frans to ask that when > someone renames a not previously documented variable to go ahead and > document it too (since they must have some knowledge of how it works, and > some correct knowledge being written down is better than none). Thanks, Tom! Yes, pushing Chase's patch for documentation update is on my TODO list for later today - I'm giving people last chance to comment... I agree, updating documentation is very desirable, no objections here. I was merely commenting on Frans' note here, giving some background: >>> Hi Chase, >>> I see you indeed as the submitter. The commit carries your name and >>> there is no reference in the commit message of another author. -- Denys ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-10 20:43 ` Denys Dmytriyenko @ 2010-09-11 9:19 ` Frans Meulenbroeks 0 siblings, 0 replies; 24+ messages in thread From: Frans Meulenbroeks @ 2010-09-11 9:19 UTC (permalink / raw) To: openembedded-devel 2010/9/10 Denys Dmytriyenko <denis@denix.org>: > On Fri, Sep 10, 2010 at 01:32:39PM -0700, Tom Rini wrote: >> Denys Dmytriyenko wrote: >>> On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote: >>>> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>: > > Yes, pushing Chase's patch for documentation update is on my TODO list for > later today - I'm giving people last chance to comment... Thanks alot! > > I agree, updating documentation is very desirable, no objections here. I was > merely commenting on Frans' note here, giving some background: > >>>> Hi Chase, >>>> I see you indeed as the submitter. The commit carries your name and >>>> there is no reference in the commit message of another author. Actually I was not really aware of SOC_FAMILY existing already. I was triggered by this message which hinted Chase was the owner: http://thread.gmane.org/gmane.comp.handhelds.openembedded/35141/focus=35236 (and there was no ref to the patch you mentioned). Anyway, it is documented and that is good! Frans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-10 18:57 ` Denys Dmytriyenko 2010-09-10 20:32 ` Tom Rini @ 2010-09-12 7:40 ` Frans Meulenbroeks 2010-09-21 18:28 ` Denys Dmytriyenko 1 sibling, 1 reply; 24+ messages in thread From: Frans Meulenbroeks @ 2010-09-12 7:40 UTC (permalink / raw) To: openembedded-devel 2010/9/10 Denys Dmytriyenko <denis@denix.org>: :> > Frans, > > I guess then you haven't read the original discussion closely enough. Chase > only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE > variable... I keep repeating myself - SOC_FAMILY feature is about a year old. > It was introduced as part of a large merge from Arago. Here is the original > commit and some description: > > http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816 I did some more research on this, as I could not recall any specific info. The patch you give above is from dec, so 9 months old. At that time it was not discussed at the mailing list as far as I can see. As the commit message said "recipes/ti: merge in updates" I (and I guess most of the non-ti devs) gave little attention to it. Also I did a quick grep on the source tree. Currently it is only used in the following files frans@linux-suse:~/oe/openembedded> grep -r SOC_FAMILY . ./conf/local.conf:SOC_FAMILY_local = "none" ./conf/distro/include/angstrom.inc:SOC_FAMILY ?= "Unknown" ./conf/distro/include/angstrom.inc:# Add FEED_ARCH and SOC_FAMILY to overrides ./conf/distro/include/angstrom.inc:OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}" ./conf/machine/include/dm6467.inc:SOC_FAMILY = "dm6467" ./conf/machine/include/omap3.inc:SOC_FAMILY = "omap3" ./conf/machine/include/omapl137.inc:SOC_FAMILY = "omapl137" ./conf/machine/include/dm365.inc:SOC_FAMILY = "dm365" ./conf/machine/include/dm6446.inc:SOC_FAMILY = "dm6446" ./conf/machine/include/dm355.inc:SOC_FAMILY = "dm355" ./conf/machine/include/omapl138.inc:SOC_FAMILY = "omapl138" ./recipes/ti/ti-linuxutils.inc: case ${SOC_FAMILY} in ./recipes/ti/ti-linuxutils.inc: if [ ${SOC_FAMILY} == "dm365" ] ; then ./recipes/ti/ti-local-power-manager.inc:# SOC_FAMILY configuration ./recipes/ti/ti-codec-engine.inc:# SOC_FAMILY configuration ./recipes/ti/ti-dsplink.inc:# SOC_FAMILY configuration ./classes/base.bbclass: this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1) Anyway, wrt the breakage, I'll push the patch for now as it has been out for review quite a while (and I got an ack and a looks good). If SOC_FAMILY is not desired we can also revert that one. Frans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-12 7:40 ` Frans Meulenbroeks @ 2010-09-21 18:28 ` Denys Dmytriyenko 0 siblings, 0 replies; 24+ messages in thread From: Denys Dmytriyenko @ 2010-09-21 18:28 UTC (permalink / raw) To: openembedded-devel On Sun, Sep 12, 2010 at 09:40:30AM +0200, Frans Meulenbroeks wrote: > 2010/9/10 Denys Dmytriyenko <denis@denix.org>: > :> > > Frans, > > > > I guess then you haven't read the original discussion closely enough. Chase > > only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE > > variable... I keep repeating myself - SOC_FAMILY feature is about a year old. > > It was introduced as part of a large merge from Arago. Here is the original > > commit and some description: > > > > http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816 Frans, Sorry for the delay in replying - I was awfully busy lately. And thank you for your continuing interest in SOC_FAMILY feature. :) > I did some more research on this, as I could not recall any specific info. > The patch you give above is from dec, so 9 months old. Since it was a merge from arago, you can add couple more months for the design and initial implementation... :) > At that time it was not discussed at the mailing list as far as I can > see. As the commit message said "recipes/ti: merge in updates" > I (and I guess most of the non-ti devs) gave little attention to it. > > Also I did a quick grep on the source tree. Currently it is only used > in the following files > > frans@linux-suse:~/oe/openembedded> grep -r SOC_FAMILY . > ./conf/local.conf:SOC_FAMILY_local = "none" > ./conf/distro/include/angstrom.inc:SOC_FAMILY ?= "Unknown" > ./conf/distro/include/angstrom.inc:# Add FEED_ARCH and SOC_FAMILY to overrides > ./conf/distro/include/angstrom.inc:OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}" > ./conf/machine/include/dm6467.inc:SOC_FAMILY = "dm6467" > ./conf/machine/include/omap3.inc:SOC_FAMILY = "omap3" > ./conf/machine/include/omapl137.inc:SOC_FAMILY = "omapl137" > ./conf/machine/include/dm365.inc:SOC_FAMILY = "dm365" > ./conf/machine/include/dm6446.inc:SOC_FAMILY = "dm6446" > ./conf/machine/include/dm355.inc:SOC_FAMILY = "dm355" > ./conf/machine/include/omapl138.inc:SOC_FAMILY = "omapl138" > ./recipes/ti/ti-linuxutils.inc: case ${SOC_FAMILY} in > ./recipes/ti/ti-linuxutils.inc: if [ ${SOC_FAMILY} == "dm365" ] ; then > ./recipes/ti/ti-local-power-manager.inc:# SOC_FAMILY configuration > ./recipes/ti/ti-codec-engine.inc:# SOC_FAMILY configuration > ./recipes/ti/ti-dsplink.inc:# SOC_FAMILY configuration > ./classes/base.bbclass: this_soc_family = > bb.data.getVar('SOC_FAMILY', d, 1) That is not a correct assessment. As you see, SOC_FAMILY is a variable, which being mostly used in overrides, so it is referenced not by variable name, but by its value. See a more accurate grep below... > Anyway, wrt the breakage, I'll push the patch for now as it has been > out for review quite a while (and I got an ack and a looks good). > If SOC_FAMILY is not desired we can also revert that one. Thank you for taking care of the fix. $ grep '[_:\"|]\(omap3\|omapl137\|omapl138\|dm355\|dm365\|dm6446\|dm6467\)[ :\"|]' . -r|grep -v -e '.patch' -e '.diff' conf/machine/include/omapl137.inc:SOC_FAMILY = "omapl137" conf/machine/include/dm6467.inc:SOC_FAMILY = "dm6467" conf/machine/include/omap3.inc:SOC_FAMILY = "omap3" conf/machine/include/dm355.inc:SOC_FAMILY = "dm355" conf/machine/include/dm365.inc:SOC_FAMILY = "dm365" conf/machine/include/omapl138.inc:SOC_FAMILY = "omapl138" conf/machine/include/dm6446.inc:SOC_FAMILY = "dm6446" conf/machine/nokia900.conf:SOC_FAMILY = "omap3" conf/distro/include/angstrom-codec-engine-2.25.02-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00" conf/distro/include/angstrom-codec-engine-2.25.02-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00" conf/distro/include/angstrom-codec-engine-latestproduction-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00" conf/distro/include/angstrom-codec-engine-latestproduction-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00" conf/distro/include/angstrom-codec-engine-latest-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00" conf/distro/include/angstrom-codec-engine-latest-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00" conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00" conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00" docs/usermanual/chapters/common_use_cases.xml: "omap3" and this value can be used in overrides to prevent recipes/ti/ti-audio-soc-example.inc:PLATFORM_da830-omapl137-evm = "omapl137" recipes/ti/ti-audio-soc-example.inc:PLATFORM_da850-omapl138-evm = "omapl138" recipes/ti/ti-codecs-omap3530_1.01.00.bb:DSPSUFFIX_omap3 = "x64P" recipes/ti/ti-dmai.inc:DEPENDS_append_dm6446 = " ti-codecs-dm6446 ti-dspbios ti-cgt6x ti-linuxutils" recipes/ti/ti-dmai.inc:DEPENDS_append_dm6467 = " ti-codecs-dm6467 ti-dspbios ti-cgt6x ti-linuxutils" recipes/ti/ti-dmai.inc:DEPENDS_append_omap3 = " ti-codecs-omap3530 ti-dspbios ti-cgt6x ti-linuxutils" recipes/ti/ti-dmai.inc:DEPENDS_append_dm355 = " ti-codecs-dm355" recipes/ti/ti-dmai.inc:DEPENDS_append_dm365 = " ti-codecs-dm365" recipes/ti/ti-dmai.inc:DEPENDS_append_omapl137 = " ti-codecs-omapl137 ti-dspbios ti-cgt6x ti-linuxutils" recipes/ti/ti-dmai.inc:DEPENDS_append_omapl138 = " ti-codecs-omapl138 ti-dspbios ti-cgt6x ti-linuxutils" recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm6446 = "dm6446_al" recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm6467 = "dm6467_al" recipes/ti/ti-dmai.inc:DMAIPLATFORM_omap3 = "o3530_al" recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm355 = "dm355_al" recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm365 = "dm365_al" recipes/ti/ti-dmai.inc:DMAIPLATFORM_omapl137 = "ol137_al" recipes/ti/ti-dmai.inc:DMAIPLATFORM_omapl138 = "ol138_al" recipes/ti/ti-dmai.inc:#GPPOS_dm355 = "LINUX_GCC" recipes/ti/ti-dmai.inc:#GPPOS_dm365 = "LINUX_GCC" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm6446 += "ti-codecs-dm6446-server ti-cmem-module ti-dsplink-module" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm6467 += "ti-codecs-dm6467 ti-cmem-module ti-dsplink-module" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_omap3 += "ti-codecs-omap3530-server ti-cmem-module ti-dsplink-module ti-lpm-module ti-sdma-module" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm355 += "ti-codecs-dm355 ti-cmem-module ti-dm355mm-module" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm365 += "ti-codecs-dm365 ti-cmem-module ti-dm365mm-module ti-edma-module ti-irq-module" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_omapl137 += "ti-codecs-omapl137-server ti-cmem-module ti-dsplink-module" recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_omapl138 += "ti-codecs-omapl138-server ti-cmem-module ti-dsplink-module" recipes/ti/gstreamer-ti.inc:PLATFORM_dm6446 = "dm6446" recipes/ti/gstreamer-ti.inc:PLATFORM_dm6467 = "dm6467" recipes/ti/gstreamer-ti.inc:PLATFORM_omap3 = "omap3530" recipes/ti/gstreamer-ti.inc:PLATFORM_dm355 = "dm355" recipes/ti/gstreamer-ti.inc:PLATFORM_dm365 = "dm365" recipes/ti/gstreamer-ti.inc:PLATFORM_omapl137 = "omapl137" recipes/ti/gstreamer-ti.inc:PLATFORM_omapl138 = "omapl138" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm6446 = "ti.platforms.evmDM6446" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm6467 = "ti.platforms.evmDM6467" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_omap3 = "ti.platforms.evm3530" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm355 = "ti.platforms.evmDM355" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm365 = "ti.platforms.evmDM365" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_omapl137 = "ti.platforms.evmOMAPL137" recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_omapl138 = "ti.platforms.evmOMAPL138" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm6446 += "ti-codecs-dm6446-server ti-cmem-module ti-dsplink-module" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm6467 += "ti-codecs-dm6467 ti-cmem-module ti-dsplink-module" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_omap3 += "ti-codecs-omap3530-server ti-cmem-module ti-dsplink-module ti-lpm-module ti-sdma-module" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm355 += "ti-codecs-dm355 ti-cmem-module ti-dm355mm-module" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm365 += "ti-codecs-dm365 ti-cmem-module ti-dm365mm-module ti-edma-module ti-irq-module" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_omapl137 += "ti-codecs-omapl137-server ti-cmem-module ti-dsplink-module" recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_omapl138 += "ti-codecs-omapl138-server ti-cmem-module ti-dsplink-module" recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_dm365 = " file://loadmodules.sh" recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_omapl137 = " file://loadmodules.sh" recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_omapl138 = " file://loadmodules.sh " recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_omap3 = " file://loadmodules.sh " recipes/ti/ti-codecs-dm6467_1.00.00.03.bb:DSPSUFFIX_dm6467 = "x64P" recipes/ti/ti-codec-engine.inc:DEPENDS_append_dm6446 = " ti-dspbios ti-dsplink ti-local-power-manager ti-cgt6x ti-biosutils ti-edma3lld" recipes/ti/ti-codec-engine.inc:DEPENDS_append_dm6467 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld" recipes/ti/ti-codec-engine.inc:DEPENDS_append_omapl137 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld" recipes/ti/ti-codec-engine.inc:DEPENDS_append_omapl138 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm6446 = "DM6446" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm6467 = "DM6467" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_omap3 = "OMAP3530" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm355 = "DM355" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm365 = "DM365" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_omapl137 = "OMAPL137" recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_omapl138 = "OMAPL138" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm6446 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm6467 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_omap3 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm355 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm365 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_omapl137 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_omapl138 = "LINUX_GCC" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm6446 = "APP_CLIENT DSP_SERVER" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm6467 = "APP_CLIENT DSP_SERVER" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_omap3 = "APP_CLIENT DSP_SERVER" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm355 = "APP_LOCAL" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm365 = "APP_LOCAL" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_omapl137 = "APP_CLIENT DSP_SERVER" recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_omapl138 = "APP_CLIENT DSP_SERVER" recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_dm6446 = " ti-dsplink-module ti-lpm-module" recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_dm6467 = " ti-dsplink-module" recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_omap3 = " ti-dsplink-module ti-lpm-module" recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_omapl137 = " ti-dsplink-module" recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_omapl138 = " ti-dsplink-module" recipes/ti/ti-codecs-omapl137_1.00.00.bb:DSPSUFFIX_omapl137 = "x64P" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm355 = "dm355" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm365 = "dm365" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm6446 = "dm6446" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm6467 = "dm6467" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_omap3 = "omap3530" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_omapl137 = "ol137" recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_omapl138 = "ol138" recipes/ti/ti-dvsdk-demos.inc:RDEPENDS_ti-dvsdk-demos_dm355 += "ti-dm355mm-module ti-cmem-module alsa-lib libpng freetype jpeg libpng12" recipes/ti/ti-dvsdk-demos.inc:RDEPENDS_ti-dvsdk-demos_dm365 += "ti-dm365mm-module ti-cmem-module alsa-lib libpng freetype jpeg ti-codecs-dm365 ti-edma-module ti-irq-module libpng12" recipes/ti/ti-linuxutils.inc: if [ ${SOC_FAMILY} == "dm365" ] ; then recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_dm6446 = "DAVINCI" recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_dm6467 = "DAVINCIHD" recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_omapl137 = "OMAPL1XX" recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_omapl138 = "OMAPL138" recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_omap3 = "OMAP3530" recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_dm6446 = "DM6446GEMSHMEM" recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_dm6467 = "DM6467GEMSHMEM" recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_omapl137 = "OMAPL1XXGEMSHMEM" recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_omapl138 = "OMAPL138GEMSHMEM" recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_omap3 = "OMAP3530SHMEM" recipes/ti/ti-dsplink.inc:DSPLINKDSP_dm6446 = "DM6446GEM_0" recipes/ti/ti-dsplink.inc:DSPLINKDSP_dm6467 = "DM6467GEM_0" recipes/ti/ti-dsplink.inc:DSPLINKDSP_omapl137 = "OMAPL1XXGEM_0" recipes/ti/ti-dsplink.inc:DSPLINKDSP_omapl138 = "OMAPL138GEM_0" recipes/ti/ti-dsplink.inc:DSPLINKDSP_omap3 = "OMAP3530_0" recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_dm6446 = "DM6446LSP" recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_dm6467 = "DM6467LSP" recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_omapl137 = "ARM" recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_omapl138 = "ARM" recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_omap3 = "OMAPLSP" recipes/ti/ti-dsplink.inc:RDEPENDS_ti-dsplink-examples_append_omap3 += " ti-lpm-module ti-lpm-utils" recipes/ti/ti-codecs-omapl138_1.00.00.bb:DSPSUFFIX_omapl138 = "x64P" recipes/ti/ti-codecs-omap3530_1.00.01.bb:DSPSUFFIX_omap3 = "x64P" recipes/ti/ti-codec-engine_2.25.01.06.bb:SRC_URI_append_dm365 += "file://loadmodules.sh" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm6446 = "trunk" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm6467 = "branches/GITPSP_INT_101009" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_omap3 = "trunk" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm355 = "branches/GITPSP_INT_101009" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm365 = "branches/GITPSP_INT_101009" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_omapl137 = "trunk" recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_omapl138 = "trunk" recipes/ti/ti-dmai_svn.bb:SRCREV_dm6446 = "423" recipes/ti/ti-dmai_svn.bb:SRCREV_dm6467 = "441" recipes/ti/ti-dmai_svn.bb:SRCREV_omap3 = "423" recipes/ti/ti-dmai_svn.bb:SRCREV_dm355 = "424" recipes/ti/ti-dmai_svn.bb:SRCREV_dm365 = "441" recipes/ti/ti-dmai_svn.bb:SRCREV_omapl137 = "423" recipes/ti/ti-dmai_svn.bb:SRCREV_omapl138 = "423" recipes/ti/ti-local-power-manager.inc:LPMDSPPOWERSOC_omap3 = "omap3530" recipes/ti/ti-local-power-manager.inc:LPMDSPPOWERSOC_dm6446 = "dm6446" recipes/ti/ti-local-power-manager.inc:XDC_PLATFORM_dm6446 = "ti.platforms.evmDM6446" recipes/ti/ti-local-power-manager.inc:XDC_PLATFORM_omap3 = "ti.platforms.evm3530" recipes/ti/ti-codecs-dm6446_2.05.00.00.bb:DSPSUFFIX_dm6446 = "x64P" recipes/ti/ti-codecs-dm6467_1.00.00.08.bb:DSPSUFFIX_dm6467 = "x64P" recipes/ti/ti-paths.inc:DSPSUFFIX_omapl137 = "x674" recipes/ti/ti-paths.inc:DSPSUFFIX_omapl138 = "x674" recipes/tasks/task-arago-toolchain-dvsdk-host.bb:DVSDK_HOST_PACKAGE_dm6446 = "\ recipes/tasks/task-arago-toolchain-dvsdk-host.bb:DVSDK_HOST_PACKAGE_dm6467 = "\ recipes/tasks/task-arago-toolchain-dvsdk-host.bb:DVSDK_HOST_PACKAGE_omap3 = "\ recipes/xorg-xserver/xserver-xorg-conf_0.1.bb:RDEPENDS_omap3 = "xf86-video-omapfb" recipes/egl/egl.inc:COMPATIBLE_MACHINE = "omap3" recipes/powertop/powertop_svn.bb:CFLAGS_append_omap3 = " -DOMAP3" recipes/kexecboot/linux-kexecboot_2.6.32.bb:S_omap3 = "${WORKDIR}/git" recipes/kexecboot/linux-kexecboot_2.6.32.bb:DEFAULT_PREFERENCE_omap3 = "1" recipes/kexecboot/linux-kexecboot_2.6.32.bb:SRC_URI_append_omap3 = " git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git;protocol=git;rev=6833f1a8cdcb65a370f898bde6b6af63f81962df \ recipes/kexecboot/kexecboot.inc:EXTRA_OECONF_omap3 = "--with-uimage" recipes/linux/linux-davinci_git.bb:SRCREV_dm355 = ${ARAGO_DM_REV} recipes/linux/linux-davinci_git.bb:SRCREV_dm365 = ${ARAGO_DM_REV} recipes/linux/linux-davinci_git.bb:SRCREV_dm6446 = ${ARAGO_DM_REV} recipes/linux/linux-davinci_git.bb:SRCREV_dm6467 = ${ARAGO_DM_REV} recipes/linux/linux-davinci_git.bb:PV_dm355 = ${ARAGO_DM_PV} recipes/linux/linux-davinci_git.bb:PV_dm365 = ${ARAGO_DM_PV} recipes/linux/linux-davinci_git.bb:PV_dm6446 = ${ARAGO_DM_PV} recipes/linux/linux-davinci_git.bb:PV_dm6467 = ${ARAGO_DM_PV} recipes/linux/linux-davinci_git.bb:BRANCH_dm355 = ${ARAGO_DM_BR} recipes/linux/linux-davinci_git.bb:BRANCH_dm365 = ${ARAGO_DM_BR} recipes/linux/linux-davinci_git.bb:BRANCH_dm6446 = ${ARAGO_DM_BR} recipes/linux/linux-davinci_git.bb:BRANCH_dm6467 = ${ARAGO_DM_BR} recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm355 = ${ARAGO_DM_URI} recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm365 = ${ARAGO_DM_URI} recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm6446 = ${ARAGO_DM_URI} recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm6467 = ${ARAGO_DM_URI} recipes/jack/jack_0.118.0.bb:PACKAGE_ARCH_omap3 = "${MACHINE_ARCH}" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 7:45 ` Frans Meulenbroeks @ 2010-09-07 14:43 ` Maupin, Chase 2010-09-08 3:47 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-09 9:26 ` Phil Blundell 2010-09-12 8:11 ` Koen Kooi 3 siblings, 1 reply; 24+ messages in thread From: Maupin, Chase @ 2010-09-07 14:43 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org > add global OVERRIDES ${TARGET_SOC_FAMILY} and > ${TARGET_ARCH}_${TARGET_SOC_FAMILY} > For my part I would ask why you are renaming SOC_FAMILY to TARGET_SOC_FAMILY? Why not leave the name the way it is since others may be using it in overlays, etc? Also, you might want to make sure your patch would include Fran's fix to base.bbclass that he mentioned at http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/023680.html For what my input is worth I would NAK this patch because: 1. I don't see a reason to add this to the generic set of overrides. 2. I don't understand why the name of the variable SOC_FAMILY needs to be changed. I know this will break existing overlays and I don't see any reason why the change is made. 3. I disagree with the ${TARGET_ARCH}_${TARGET_SOC_FAMILY} override. If you have two patch series for different architectures then you should have two SOC_FAMILY settings or use the MACHINE setting for the override. I think this override is confusing and redundant. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-07 14:43 ` Maupin, Chase @ 2010-09-08 3:47 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 0 replies; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-08 3:47 UTC (permalink / raw) To: openembedded-devel On 09:43 Tue 07 Sep , Maupin, Chase wrote: > > add global OVERRIDES ${TARGET_SOC_FAMILY} and > > ${TARGET_ARCH}_${TARGET_SOC_FAMILY} > > > For my part I would ask why you are renaming SOC_FAMILY to TARGET_SOC_FAMILY? Why not leave the name the way it is since others may be using it in overlays, etc? to be consistant it's the TARGET SOC FAMILY not the host as the ARCH > > Also, you might want to make sure your patch would include Fran's fix to base.bbclass that he mentioned at http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/023680.html > > For what my input is worth I would NAK this patch because: > > 1. I don't see a reason to add this to the generic set of overrides. because you need for SoC support and it's not distrib related but hardware related (SoC familly) > 2. I don't understand why the name of the variable SOC_FAMILY needs to be changed. I know this will break existing overlays and I don't see any reason why the change is made. > 3. I disagree with the ${TARGET_ARCH}_${TARGET_SOC_FAMILY} override. If you have two patch series for different architectures then you should have two SOC_FAMILY settings or use the MACHINE setting for the override. I think this override is confusing and redundant. no as I describe already the same doc familly can be run on two or more ARCH so this make sens and no it's no the machine to handle this but each receipe and no it's not redundant at all it's more precises as at receipe level you may we do this SRC_URI_arm += patches SRC_URI_arm_mnt += patches SRC_URI_mnt += patches SRC_URI_mips += patches SRC_URI_mips_mnt += patches so yes it's need Best Regards, J. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 7:45 ` Frans Meulenbroeks 2010-09-07 14:43 ` Maupin, Chase @ 2010-09-09 9:26 ` Phil Blundell 2010-09-12 8:11 ` Koen Kooi 3 siblings, 0 replies; 24+ messages in thread From: Phil Blundell @ 2010-09-09 9:26 UTC (permalink / raw) To: openembedded-devel On Sat, 2010-09-04 at 05:14 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: > diff --git a/conf/bitbake.conf b/conf/bitbake.conf > index 677c76a..672d8df 100644 > --- a/conf/bitbake.conf > +++ b/conf/bitbake.conf > @@ -113,6 +113,8 @@ TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS' > TARGET_PREFIX = "${TARGET_SYS}-" > TARGET_CC_ARCH = "" > TARGET_EXEEXT = "" > +TARGET_SOC_FAMILY ?= "Unknown" > + > > SDK_ARCH ?= "${BUILD_ARCH}" > SDK_OS ?= "${BUILD_OS}" > @@ -677,9 +679,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS" > # > # This works for functions as well, they are really just environment variables. > # Default OVERRIDES to make compilation fail fast in case of build system misconfiguration. > -OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}" > +OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${TARGET_SOC_FAMILY}:${TARGET_ARCH}_${TARGET_SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}" I don't have much of an opinion on the renaming, but the overrides part will cause an unacceptable level of namespace pollution. As it stands, everybody will suddenly get "Unknown" in their OVERRIDES and this is not at all desirable. If you must add these kinds of things to the default OVERRIDES then they need a suitable namespace prefix, for example something like soc-family-${SOC_FAMILY}. (Alternatively, put it in your own DISTRO configuration where you can do whatever you like.) p. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD ` (2 preceding siblings ...) 2010-09-09 9:26 ` Phil Blundell @ 2010-09-12 8:11 ` Koen Kooi 2010-09-13 2:45 ` Jean-Christophe PLAGNIOL-VILLARD 3 siblings, 1 reply; 24+ messages in thread From: Koen Kooi @ 2010-09-12 8:11 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04-09-10 05:14, Jean-Christophe PLAGNIOL-VILLARD wrote: > add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY} NAK, introducing a new override that combines 2 existing overrides with a '_', is not allowed. And it isn't needed as Chase has tried to point out already You're also changing the overrides order, which needs a lot more testing and ACKs from the people using it. ANd furthermore you're renaming it to have more underscores (adding 'TARGET_', while it was decided at OEDEM that using underscored should be avoided, since it's out override seperator. regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFMjIsoMkyGM64RGpERAjInAJ9XtBKSH7FYLqxisI8qoG0QlDInMgCgjJ0T NohqEHEYaIp6DB3mrMi+zlU= =nCWu -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global 2010-09-12 8:11 ` Koen Kooi @ 2010-09-13 2:45 ` Jean-Christophe PLAGNIOL-VILLARD 0 siblings, 0 replies; 24+ messages in thread From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-13 2:45 UTC (permalink / raw) To: openembedded-devel On 10:11 Sun 12 Sep , Koen Kooi wrote: > On 04-09-10 05:14, Jean-Christophe PLAGNIOL-VILLARD wrote: > > add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY} > > NAK, introducing a new override that combines 2 existing overrides with > a '_', is not allowed. And it isn't needed as Chase has tried to point > out already except I do point case where it's really needed and I'm working on adding new soc to oe and I do need it > > You're also changing the overrides order, which needs a lot more testing > and ACKs from the people using it. currently only TI package use it and here the idea is not to change the order but extend it > > ANd furthermore you're renaming it to have more underscores (adding > 'TARGET_', while it was decided at OEDEM that using underscored should > be avoided, since it's out override seperator. so we need to rename all TARGET_ to TARGET-??? Best Regards, J. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-09-21 18:29 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-03 11:12 How to extend SRC_URI_append? Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 14:44 ` Chris Larson 2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-03 20:34 ` Maupin, Chase 2010-09-03 21:45 ` Khem Raj 2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD 2010-09-04 7:45 ` Frans Meulenbroeks 2010-09-04 8:20 ` Frans Meulenbroeks 2010-09-07 14:21 ` Maupin, Chase 2010-09-08 5:58 ` Frans Meulenbroeks 2010-09-10 18:57 ` Denys Dmytriyenko 2010-09-10 20:32 ` Tom Rini 2010-09-10 20:43 ` Denys Dmytriyenko 2010-09-11 9:19 ` Frans Meulenbroeks 2010-09-12 7:40 ` Frans Meulenbroeks 2010-09-21 18:28 ` Denys Dmytriyenko 2010-09-07 14:43 ` Maupin, Chase 2010-09-08 3:47 ` Jean-Christophe PLAGNIOL-VILLARD 2010-09-09 9:26 ` Phil Blundell 2010-09-12 8:11 ` Koen Kooi 2010-09-13 2:45 ` Jean-Christophe PLAGNIOL-VILLARD
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.