news.eclipse.dsdp.rtsc

[news.eclipse.dsdp.rtsc] Re: XDC build error with specific XDCARGS

badri@xxxxxxx (Badri ) — Thu, 02 Jul 2009 10:31:47 GMT

Dave, Thank you for the reply. The error is generated when XDC generates the makefile from the package.bld and that is why i suspect it to be an XDC tools issue.

My package name is ti.sdo.domx.domxcore If I give xdc all A file ti.sdo.domx.domxcore.a64P.mak is generated in the ti/sdo/domx/domxcore/lib folder.

If I give xdc all XDCARGS=SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04 the xdc tools tries to generate the makefile under ti/sdo/domx/domxcore/lib/SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04/ti.sdo.domx.av5T.mak which fails.

The error is generated by xdctools_3_15_00_50\include\utils.tci utils.saveFile = function (content, fileName)

Please let me know if this error is occuring due to some wrong configuration in package.bld

[news.eclipse.dsdp.rtsc] Re: XDC build error with specific XDCARGS

d-russo@xxxxxxx (dave russo) — Tue, 30 Jun 2009 16:51:01 GMT

Badri wrote:

Champs, I am using XDC tools version 3.15.00.50 on Windows. I am seeing that the xdc build fails with message: "can't create directory syslink_2_00_00_04" on giving the following XDC build command line: xdc all XDCARGS="SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04"

Looks like XDC tools tries to create a mak file under lib/ folder of the form

lib/SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04/ti.sdo.domx.domxcore.av5T.mak
which fails on windows.
Can you please let me know how to escape the XDCARGS so that this does not occur

XDCARGS is "uninterpreted" by XDCtools; it is simply passed to package build scripts; see http://rtsc.eclipse.org/docs-tip/Command_-_xdc#Environment_Variables

This looks like a SysLink question but, if I had to guess, I'd try dropping the XDCARGS assignment:

    xdc all SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04

Recall that the xdc command is just GNU make and GNU make allows one to define values on the command line via simple name=value pairs.


Thanks
Badri

[news.eclipse.dsdp.rtsc] XDC build error with specific XDCARGS

badri@xxxxxxx (Badri ) — Tue, 30 Jun 2009 09:47:32 GMT

Champs, I am using XDC tools version 3.15.00.50 on Windows. I am seeing that the xdc build fails with message: "can't create directory syslink_2_00_00_04" on giving the following XDC build command line: xdc all XDCARGS="SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04"

Looks like XDC tools tries to create a mak file under lib/ folder of the form

lib/SYSLINKDIR=D:/tools_wtbu_base_omx/syslink_2_00_00_04/ti.sdo.domx.domxcore.av5T.mak

which fails on windows.

Can you please let me know how to escape the XDCARGS so that this does not occur


Thanks
Badri

[news.eclipse.dsdp.rtsc] Re: Path-related Errors

d-russo@xxxxxxx (dave russo) — Mon, 29 Jun 2009 19:33:10 GMT

Brad Griffis wrote:

I've been discussing this topic with Dave and wanted to make it more visible. Here are what I *think* we've agreed to, though I'm sure Dave will chime in if I've misrepresented him!
This all relates to the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=277233
I was concerned/disappointed that the fix did not include a check for paths on XDCPATH with no valid packages on them. The RTSC team did not want this added because they didn't want builds to take an excessive amount of time to fail.

Supposedly this check and others are part of the current "Path tool". I checked this behavior in the past and it didn't catch these issues, but supposedly it has been fixed now. The other major problem with the path tool is that you have to add all your paths to it, i.e. that's one more thing to do as you're trying to figure out why your project won't build. So this new proposal focuses on making it really easy to launch the Path tool with the proper paths ready to go.

Short term solution * Step 1: The Path tool needs an option to fully specify the path at the command line. * Step 2: The error message from configuro should be modified to include directions that tell someone to copy/paste to the command prompt such that it launches the Path tool with the proper path without having to do any monkeying around. Just copy, paste, enter and it should be running and fully configured.

Long term solution * Longer term it would be nice to have something integrated into Eclipse such that you can double-click your "package not found" error and have the path tool automatically launched and fully configured. * That solution can be extended such that any XDC related error can be double-clicked and you can get further info, etc.

Other comments/suggestions are welcome. I hope Dave and the team will commit to getting my short-term solution out the door ASAP since path-issues are a real thorn in the side of newbies to RTSC.

I'd prefer to directly attack the "long-term" solution rather than a near-term/long-term approach. The "long-term" solution is not that difficult and it's less work to solve the only slightly more general problem of providing trouble shooting advice for common errors.

Rather than creating long error messages in the short term (which requires a re-release of the product), we can update the trouble shooting section of the on-line docs (http://rtsc.eclipse.org/docs-tip/Trouble_Shooting).

There are a number of other errors that would benefit from an error parser: http://rtsc.eclipse.org/docs-tip/XDCtools_Error_Codes. By creating a RTSC error parser (and integrating it into eclipse), the user only needs to remember to run the parser on their build log (or double-click the problem in eclipse). Having an error parser 1. allows the expert user to not be burdened by verbose messages 2. helps prevent excessive build times when errors occur, 3. provides the novice user detailed trouble shooting advice, and 4. enables the XDCtools code base to use traditional error reporting mechanisms (like that of a compiler)

[news.eclipse.dsdp.rtsc] Re: XDC Producer's Guide

bob@xxxxxxx (Bob Frankel) — Thu, 25 Jun 2009 02:29:35 GMT

the contents of the 'Programming Model' binder at the RTSC-pedia are primarily producer-centric -- everything from how to produce a RTSC module, abstract its functionality in a RTSC interface, and deliver the goods within a RTSC package.... [there is a Scripting Primer to complete the set, focusing on use of meta-language primarily from the producer's perspective -- how to write apps in the meta-language, use of templates to facade config of legacy content, etc....

are you looking for something beyond this???

Brad Griffis wrote:

At one point in time a "XDC Producer's Guide" was being written. Whatever happened to it?

[news.eclipse.dsdp.rtsc] XDC Producer's Guide

bgriffis@xxxxxxx (Brad Griffis) — Wed, 24 Jun 2009 15:24:12 GMT

At one point in time a "XDC Producer's Guide" was being written. Whatever happened to it?

[news.eclipse.dsdp.rtsc] Re: Configuro Output

bgriffis@xxxxxxx (Brad Griffis) — Wed, 24 Jun 2009 15:21:16 GMT

dave russo wrote:

Brad Griffis wrote:
Yes, I think a --quiet would be good. In the case of some kind of error/warning then it would be good for it to tell us that it's an error compiling a file or whatever it might be. In other words, don't tell me what you're doing unless something goes wrong. In most cases I would expect/hope to get enough info from the error message to fix the problem without having to turn off --quiet and re-do the build.

So potentially this may require a little re-working of some error messages. If the error message is overly dependent on the user having all the status info then we may want to repeat that info in the error message.

The problem is that the configuration process involves many tools that XDC does not control; as a result, many of the error messages _can't_ be changed. For example, errors can come from the target's compiler/linker, GNU make, cygwin, ...

Let's try it out and we'll see how it goes. If nothing else, once we get things building properly it will be nice to throw the --quiet switch and simplify/shrink the build output.

[news.eclipse.dsdp.rtsc] Re: Configuro Output

d-russo@xxxxxxx (dave russo) — Wed, 17 Jun 2009 16:42:58 GMT

Brad Griffis wrote:

Yes, I think a --quiet would be good. In the case of some kind of error/warning then it would be good for it to tell us that it's an error compiling a file or whatever it might be. In other words, don't tell me what you're doing unless something goes wrong. In most cases I would expect/hope to get enough info from the error message to fix the problem without having to turn off --quiet and re-do the build.

So potentially this may require a little re-working of some error messages. If the error message is overly dependent on the user having all the status info then we may want to repeat that info in the error message.

The problem is that the configuration process involves many tools that XDC does not control; as a result, many of the error messages _can't_ be changed. For example, errors can come from the target's compiler/linker, GNU make, cygwin, ...

[news.eclipse.dsdp.rtsc] Re: Configuro Output

bgriffis@xxxxxxx (Brad Griffis) — Wed, 17 Jun 2009 16:08:17 GMT

Yes, I think a --quiet would be good. In the case of some kind of error/warning then it would be good for it to tell us that it's an error compiling a file or whatever it might be. In other words, don't tell me what you're doing unless something goes wrong. In most cases I would expect/hope to get enough info from the error message to fix the problem without having to turn off --quiet and re-do the build.

So potentially this may require a little re-working of some error messages. If the error message is overly dependent on the user having all the status info then we may want to repeat that info in the error message.

[news.eclipse.dsdp.rtsc] Re: Configuro Output

d-russo@xxxxxxx (dave russo) — Wed, 17 Jun 2009 14:48:35 GMT

Brad Griffis wrote:

Is there a way to reduce the amount of data currently being spewed out by the tools/configuro? Do we really need all the info (Generating interfaces, etc.)? For top-level build I would just want to see something like "Running configuration step for app.cfg", not all the data. What I believe is just the "normal" info being output seems more appropriate to a "verbose" output. All the stuff spewing out makes some people nervous because they feel disconnected from what's happening, i.e. too much stuff whizzing past on the screen. I think something like "Running configuration step for app.cfg" would be easier to follow. Only if something is screwed up would I want to see more.

I agree.

On the other hand, there are good reasons for keeping the output. The output provides feedback about the tools progress (which can take some time) and when something goes wrong the error message makes more sense in the context of what the tool is doing at the time. For example, errors may come from the target's compiler and, without a message saying we are compiling a specific file, it _really_ does not make sense.

Perhaps a --quite flag can be added to xdc.tools.configuro to eliminate the progress messages.