Problem building Codec Engine Examples

Thanks you, that worked.

It turns out there was a placeholder in the xdcpaths.mak file for changes to XDC_PATH.  It was at the end of the file, past a comment stating "most users have no need to modify anything below this line."  Oops.

Is there a reason the build did not work for my particular setup?  For my own education, I'm curious.

I would need to inspect your environment to determine the exact reason your build failed. Just looking at the error message above indicates the repository which contained the ti.bios.power package was not on your XDC path. Maybe it was just the missing 'packages' part or maybe the entire repository was missing. Hard to say.

What would you need to look at?  Is it as simple as posting a section of a configuration file? 

Well, lets start with the xdc command that fails and the error message. Add XDCOPTION=v to your xdc command. Post the xdc command that is echoed to your console. Also attach or post the contents of the .xdcenv.mak file in the same package. We can take it a step at a time from there.

Yes, it seems that the bug is related to issue SDOCM00053545.

I just wanted to mention that the DSPLINK_INSTALL_DIR is added to the XDC_PATH differently than the other paths.  Most paths use something like this:

XDC_PATH := $(XDC_PATH);$(BIOSUTILS_INSTALL_DIR)/packages

while DSPLINK_INSTALL_DIR uses:

XDC_PATH := $(XDC_PATH);$(DSPLINK_INSTALL_DIR)

You'll notice the 'packages' directory is not appended on the end of the directory path.  While this is certainly not a big deal, it does mean the DSPLINK directory path is not consistent with the other directory paths in xdcpaths.mak (it's the only one with /packages).

More than you asked for, but I guess it's dirty laundry day.  :)

Internally, the Codec Engine team takes a DSP Link distribution, sometimes [unfortunately] patches it, and builds it for just the config we need (e.g. MSGQ on, PROC on, CHNL off, right Linux kernel version/toolchain, etc).

Prior to the addition of WinCE support, we would also include that pre-built DSP Link into our cetools/ directory and distribute it for our customers' benefit.  Once WinCE arrived, GPL introduced licensing issues with the DSP Link distribution, and we stopped shipping it in cetools and told all our customers they had to 'get the right one (WinCE or Linux) themselves'.

Dirty secret #1 is that one of the "patches" we made to Link was to add a packages/ directory for consistency in our builds.  This should never have happened, but did, and went overlooked for years(!).

Dirty secret #2 is that historically, the DVSDK would redistribute the Codec Engine team's "patched" Link rather than get it straight from the Link team.  (Also should never have happened, but did.)  That unfortunately introduced the packages/ dir that was never a part of the official, original Link, into the DVSDK products.

Once the CE team removed Link from cetools and started telling its customers to 'get it themselves', one of those customers was the DVSDK program.  They then [correctly] started distributing Link as it was originally produced - without the packages/ dir.

All that history to say that whether Link has a packages/ dir or not, historically [unfortunately!] depends on where you get it from.  The official releases of Link never had it(!), so recent releases of CE and DVSDK are actually fixing those dirty secrets and removing it.  But customers (e.g. Codec Engine's xdcpaths.mak, Rules.make, etc) may need to modify things a little bit to get the XDCPATH 'just right', depending on how they received Link (cetools, DVSDK, or separate download).  The XDC packages in DSP Link are 'dsplink.dsp' and 'dsplink.gpp', so what needs to be on the XDCPATH is the directory that _contains_ the 'dsplink' directory.

Chris

It might have been more than I asked for, but it was very interesting to read.  Thank you!