On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> Let me preface this by I have read the patch set.. Martin asked me to comment
> on
> the items below...
>
> On 9/27/12 3:37 AM, Martin Jansa wrote:
> > On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of DEFAULTTUNE
> >>> * this way xscale or arm926ejs is not used by default when some machine
> >>> includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>> OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>> share built packages between xscale and arm926ejs).
> >>>
> >>> Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
> >>> ---
> >>> meta/conf/bitbake.conf | 1 +
> >>> meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>> meta/conf/machine/include/tune-xscale.inc | 3 ++-
> >>> 3 files changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>> index 9b41749..e433fcb 100644
> >>> --- a/meta/conf/bitbake.conf
> >>> +++ b/meta/conf/bitbake.conf
> >>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>> HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>> HOST_EXEEXT = ""
> >>>
> >>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>> TUNE_ARCH ??= "INVALID"
> >>> TUNE_CCARGS ??= ""
> >>> TUNE_LDARGS ??= ""
> >>
> >> As I've said previously, I do not think OPTDEFAULTTUNE is clear in usage
> >> or in meaning and we need to find a better solution. I'm therefore not
> >> keen on this change.
> >
> > OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> > different PKGARCH for different TUNE_CCARGS?
>
> I've been an advocate for a while that the processor optimization (CCARGS)
> does
> make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable approach to
> do
> this. It allows each tune to set something to tell people what that binary
> is
> really built for, and for the 'base' tunes (i.e. armv5) it can be left off.
>
> The only concern I have with that is:
>
> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> "-arm926ejs", "", d)}"
>
> That probably should be a .= instead of just '='. That way if the user loads
> multiple compatible tunes the right ARMPKGSFX_CPU will be used.
> (Alternatively
> using the overrides would work as well for this.. i.e.
> ARMPKGSFX_CPU_tune-arm926ejs instead...
>
> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead... This is
> fine as well, and it was designed to be overriden.. but again the .= or
> -tune_... syntax should be used...I've updated contrib/jansa/tune-test with this. http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune-test While changing that to use e.g. ARMPKGARCH_tune-xscale I've noticed that _tune-foo are not valid OVERRIDE, so I had to add ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}" in arch-arm.inc and then define ARMPKGARCH_tune-foo for every supported arm tune (otherwise it's expanded like this TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).). This makes whole TUNE_PKGARCH = "${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" a bit less usefull, maybe ARMPKGSFX_CPU was better approach.. Cheers, > > Anyway, my point in this is I like having the stuff unique, but we need to be > sure that you can specify more then one tune file during a build w/o clashes. > > >> I also still think this is a distro packaging issue and should be solved > >> by the distro, even if that means more complexity there. That is the > >> right place for this particular complexity IMO. I'm happy to support > >> that from the core but not in something as user visible and confusing as > >> this variable. > > > > Agreed OPTDEFAULTTUNE is to help distro configs, because complexity > > there will be much worse then when it's defined in tune-* files, because > > now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or > > TUNE_FEATURE) it supports and it's less orthogonal (machine/distro > > config) then it could be. > > I really don't have a strong opinion on this either way. I know for the > stuff > I've done in the past (not oe-based) we've just manually configured (the > equivalent of the distro conf) with the information on the handful of items > that > people wanted optimized the most... eglibc, openssl, mysql/posgresql... > otherwise folks don't seem to care, and re-use works fine. > > If the list is small (i.e. less then 10 packages) that specifying it via > package > specific overrides in the distro file should be fine.. if it's more then 10 > (typically) then we need to start looking for another approach. > > I'd almost suggest in the distro file you could do: > > OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the BSP > (or > elsewhere), if set use that value, otherwise using the DEFAULTTUNE value. > > DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}" > > and then everything can be encapsulated into the distro file (and distro > BSPs). > The downside of this approach is that it's not the 'standard' > implementation. > > --Mark > > > Cheers, > > > > > > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
