Eclipse Community Forums: DSDP - Real-Time Software Components (RTSC) » preserving package/info/*.js in xdc clean

Help

Home

Home » Archived » DSDP - Real-Time Software Components (RTSC) » preserving package/info/*.js in xdc clean

Show: Today's Messages :: Show Polls :: Message Navigator

preserving package/info/*.js in xdc clean [message #733]

Thu, 08 January 2009 16:37

Alan Campbell

Messages: 3
Registered: July 2009

Junior Member

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.

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?

Cheers, Alan

Report message to a moderator

Re: preserving package/info/*.js in xdc clean [message #740 is a reply to message #733]

Thu, 08 January 2009 18:35

Dave Russo

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
>

Report message to a moderator

Re: preserving package/info/*.js in xdc clean [message #745 is a reply to message #733]

Thu, 08 January 2009 19:28

Dave Russo

Messages: 172
Registered: July 2009

Senior Member

Alan Campbell wrote:

>
> i.e. there's no granularity in the 'clean'.
>
Actually there is some granularity: Rather than "xdc clean", you can
clean only files related to a specific target. For example, "xdc
clean,64P" will only remove the files related to the target whose suffix
is "64P". As a result, this does not remove the entire package
sub-directory and may solve you problem.

See the xdc man page (http://rtsc.eclipse.org/docs-tip/Command_-_xdc)
for a complete description of the target-specific goals supported by the
xdc command.

> Any ideas on bld-magic to preserve the info.js file for eval .v. prod
> depending on the xdc args?
>
> Cheers, Alan
>

Report message to a moderator

Re: preserving package/info/*.js in xdc clean [message #750 is a reply to message #740]

Thu, 08 January 2009 20:41

Alan Campbell

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
>>

Report message to a moderator

Re: preserving package/info/*.js in xdc clean [message #755 is a reply to message #750]

Fri, 09 January 2009 00:32

Dave Russo

Messages: 172
Registered: July 2009

Senior Member

Alan Campbell wrote:
>
> 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.
>
Hummmm.... "xdc clean" should remove all generated files _including_
decodeCombo.x64P. The package must have a custom makefile that creates
decodeCombo.x64P but does not remove it during a clean. Perhaps that
same custom makefile can save decodeCombo.x64P.info.js to another directory.

Alternatively, you can change the package.bld script to build _both_
eval and production "side by side". Then, when you rebuild there is no
need to clean and you can still just build one combo by naming the combo
you you want to build; e.g., "xdc decodeCombo.x64P" or "xdc
decodeCombo_e.x64P".

If you don't like typing the long names you can add some "phony" make
goals that would allow you to build production combos via "xdc prod" and
evaluation combos via "xdc eval". Simply add a custom makefile, say
custom.mak" with the following lines:

prod: decodeCombo.x64P
eval: decodeCombo_e.x64P

Then add the following line to your package.bld script:

Pkg.makePrologue = "include custom.mak";

> Its the fact that package/* is unconditionally nuked during xdc clean
> that's the problem.
>
The clean goal is defined to remove all generated files. Since all
files in ./package are generated, all files in ./package are removed.

If you want to keep some generated files across "xdc clean" invocations,
you have to add your own make file rules (e.g., using the technique
above).

>
>>> Cheers, Alan
>>>
>
>

Report message to a moderator

Previous Topic:	RTSC for ECU
Next Topic:	recommended way to put XDC paths in a file?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Dec 21 17:06:03 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter