|
Re: preserving package/info/*.js in xdc clean [message #740 is a reply to message #733] |
Thu, 08 January 2009 18:35 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Dave Russo![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=d-russo%40ti.com) Messages: 172 Registered: July 2009 |
Senior Member |
|
|
Alan Campbell wrote:
> hello,
>
> Context - in TI Davinci/OMAP codec combos/servers we want to ship
> production combos using production codecs, yet enable customers to
> rebuild and leverage evaluation codecs. Eval and prod codecs are named
> differently. We want the servers to be named differently too e.g.
> decodeCombo.x64P .v. decodeCombo_e.x64P via XDCARGS="eval"
>
> In package.bld we can do: -
> if ((arguments[0]=="") || (arguments[0]=="eval")) {
> executableName += "_e";
> }
> Pkg.addExecutable( executableName, targ, targ.platform,
> ...blah blah...
>
> But it doesnt work :-(
>
> 'xdc clean' will nuke package/info - that dir contains a golden file -
> the decodeCombo.x64P.info.js (or decodeCombo_e.x64P.info.js) which tells
> the Arm the memory map.
>
xdc clean removes all generated files. The ./package sub-directory of a
package only contains generated files. So, it's not surprising that
../package/info files are removed.
> i.e. there's no granularity in the 'clean'.
>
> Any ideas on bld-magic to preserve the info.js file for eval .v. prod
> depending on the xdc args?
>
Since the ./package/info files are not part of the files generated by
RTSC, I don't know how to best answer the question. I suspect they are
being generated by Codec Engine, but I don't know how or when.
Is the problem that they are not being regenerated? Or are you trying
to preserve _both_ info files even though you are only building one
executable?
> Cheers, Alan
>
|
|
|
|
Re: preserving package/info/*.js in xdc clean [message #750 is a reply to message #740] |
Thu, 08 January 2009 20:41 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Alan Campbell![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=a-campbell%40ti.com) Messages: 3 Registered: July 2009 |
Junior Member |
|
|
dave russo wrote:
> Alan Campbell wrote:
>> hello,
>>
>> Context - in TI Davinci/OMAP codec combos/servers we want to ship
>> production combos using production codecs, yet enable customers to
>> rebuild and leverage evaluation codecs. Eval and prod codecs are named
>> differently. We want the servers to be named differently too e.g.
>> decodeCombo.x64P .v. decodeCombo_e.x64P via XDCARGS="eval"
>>
>> In package.bld we can do: -
>> if ((arguments[0]=="") || (arguments[0]=="eval")) {
>> executableName += "_e";
>> }
>> Pkg.addExecutable( executableName, targ, targ.platform,
>> ...blah blah...
>>
>> But it doesnt work :-(
>>
>> 'xdc clean' will nuke package/info - that dir contains a golden file -
>> the decodeCombo.x64P.info.js (or decodeCombo_e.x64P.info.js) which tells
>> the Arm the memory map.
>>
> xdc clean removes all generated files. The ./package sub-directory of a
> package only contains generated files. So, it's not surprising that
> ../package/info files are removed.
>> i.e. there's no granularity in the 'clean'.
>>
>> Any ideas on bld-magic to preserve the info.js file for eval .v. prod
>> depending on the xdc args?
>>
> Since the ./package/info files are not part of the files generated by
> RTSC, I don't know how to best answer the question. I suspect they are
> being generated by Codec Engine, but I don't know how or when.
> Is the problem that they are not being regenerated? Or are you trying
> to preserve _both_ info files even though you are only building one
> executable?
The sequence of events from customer POV is: -
1. I got my decodeCombo.x64P and package/info/decodeCombo.x64P.info.js so
I can run prod codecs/combo
2. now I want to add a codec or put in updated vers of existing codec or
just rebuild the thing - so I have to use eval-codecs for that (IP issues
etc) - so now I'll rebuild & get decodeCombo_e.x64P and
package/info/decodeCombo.x64P_e.info.js
3. whoops - I just nuked my production combo cos I did an xdc clean and it
kept my decodeCombo.x64P ok but killed package/* thus killing its
mem-map-descriptor.
Its the fact that package/* is unconditionally nuked during xdc clean
that's the problem.
>> Cheers, Alan
>>
|
|
|
|
Powered by
FUDForum. Page generated in 0.04076 seconds