[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