[meta-ti] [PATCH 0/4] Resubmit TI DSP build issues related to installer

Monk, Roger r-monk at ti.com
Tue Jan 31 16:45:03 PST 2012


Hi Peter,

On Tue, Jan 31, 2012 at 12:40:53, Peter A. Bigot wrote:
> Subject: [meta-ti] [PATCH 0/4] Resubmit TI DSP build issues related to
> installer
>
> From: "Peter A. Bigot" <bigotp at acm.org>
>
> This patch set re-submits the (updated) uncommitted parts of my
> 27Dec2011 patch set to get gstreamer-ti and its dependencies to build
> in a pristine work environment.  It was left back on 29Dec2011 with:
>
> > I'm going to wait for Roger to get back from holidays to comment on
> the installer issues, I'll push the CE and dmai patches later today.
>

Thanks for re-basing/re-submitting - sorry this has taken a while.  Your patches look good - however, I have some other failing installer scenarios like these for which I have a similar, but unfortunately, not the same patchset, in progress.  I hope to review yours in the coming days if ok.

> The installer issues are:
>
> ti-eula-unpack spawns the installer, then writes canned input to it to
> do things like set the output directory.  The function that does this
> explicitly tacks a second newline on, in addition to the one normally
> added by Python's print statement.
>
> For ti-cgt6x, the result is that a bare newline is fed to the
> installer at the point where the installation directory is requested,
> instead of the workdir.  Hence, the default directory gets used; for
> this package, that's in /opt/TI.
>
> For ti-xdctools, ti-edma3lld, and ti-dspbios, the bare newline also
> caused the default installation directory to be requested, but for
> this package that's ${HOME}/ti.  Since ti-eula-unpack overrides the
> HOME environment variable to be the work directory, everything somehow
> happened to work out, at least for other folks.  I don't think that's
> a great solution though, so I updated the recipes to do it "right", by
> changing the commands to conform to what the current installers expect.
> There may be other installation recipes for other tools that need the
> same fixes.
>
> For the 31Jan2012 attempt, similar changes had to be made to
> ti-codecs- omap3530.
>
> For the 31Jan2012 attempt, the ti-dmai build required more than just
> altering the striplevel: the ${S} value had to be changed since there
> was no Makefile at its original value.  There is still an issue that
> prevents use of where make 3.85 produces a "Entering an unknown
> directory" failure in do_install, but that's an upstream problem: I
> just used make 3.81 to complete the build.
>
> Peter A. Bigot (4):
>   ti-eula-unpack: remove extraneous newline in cmd output
>   various: fix installation directories for corrected ti-eula-unpack
>   ti-codecs-omap3530: fix for corrected ti-eula-unpack
>   ti-dmai_svn: correct path within svn checkout
>
>  recipes-ti/bios/ti-dspbios.inc                     |    3 ++-
>  .../codec-engine/ti-codecs-omap3530_4.00.00.00.bb  |   20 ++++++++++--
> --------
>  recipes-ti/devtools/ti-xdctools.inc                |    3 ++-
>  recipes-ti/dmai/ti-dmai_svn.bb                     |    9 ++++++---
>  recipes-ti/edma3lld/ti-edma3lld.inc                |    3 ++-
>  recipes-ti/includes/ti-eula-unpack.inc             |    2 +-
>  6 files changed, 23 insertions(+), 17 deletions(-)
>
> --
> 1.7.6.4
>
>
Texas Instruments Limited, 800 Pavilion Drive, Northampton, NN4 7YL. Registered in England & Wales under company number 00574102

_______________________________________________
> meta-ti mailing list
> meta-ti at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti






More information about the meta-ti mailing list