On Tue, Oct 02, 2012 at 03:36:16PM -0500, Mark Hatle wrote:
> On 10/2/12 1:43 PM, Martin Jansa wrote:
> > 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..
>
> I've clarified with RP on this. Tune values are not a 'true' override
> because
> of evaluation time of overrides. We want the DEFAULTTUNE to be changeable
> during the build process to allow multilibs, alternative configurations, etc.
>
> So in the tunes to do override-like implementations, you will need:
>
> ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
>
> and then in each tune fragment:
>
> ARMPKGARCH_tune-foo = "bar"
Yes that's what I did, but it's a bit ugly, see yourself - 2nd patch from top
in that repo
>
> --Mark
>
> > 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
