• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 1391 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

XDC tools network install - btiXdc failed

Richard Zuber
Prodigy 210 points


Hello,

I am attempting to setup XDC tools in a shared network location as described by section 1.2.1 of the XDC Getting Started Guide.  When using the proceedure described here:

http://rtsc.eclipse.org/cdoc-tip/xdc/tools/configuro/ccs/package.html

I got the following error:

Can anyone help me understand what that means?  I was unable to find any reference on this forum or on Google.

My ultimate goal is to have one set of the various XDC libraries shared among all developers.  Though I have all my environment variables pointing to the correct location, when I try to create a new RTSC project in Code Composer, it claims that XDC tools are not installed.  I should also mention that the files are not actually stored on the network at the moment, just in the non-default directory with the original default install removed.

 

Thanks in advance for any insights,

Richard Zuber

 

  • 0
    TI__Expert 3550 points

    Hi Richard,

    How are you installing XDCtools over the network? Do you point to a mapped network drive when you invoke the installer?

    Also, CCSv4 needs to know where the XDCtools installation is since it is not installed in the default location. This can be done by adding the product installation folder to the tool discovery path in the dialog accessed via Window -> CCS -> RTSC -> Products in the IDE (screenshot is shown below).

     

     

     

    Once you add the new path, CCS4 will prompt a restart. After a restart you should be able to see the XDCtools product in the UI and start using it.

    Regards

    Amit

     

  • 0 in reply to AmitMookerjee
    Prodigy 210 points

    Amit,

    All I have done is move the tools that were installed with CCS4 into another folder on my machine, and deleted from the original install location. I tried the method you described above, but CCS4 was still unable to find the tools even when I added a pointer to that directory and restarted CCS as you suggested.  I could download all the original installers and choose network install.  What is the difference between the two installation methods?  I'm assuming registry settings, which was the start of my question.  I would prefer no registry settings be needed for a proper install for ease of portability to Linux workstations.

    The end goal is to have all libraries checked into version control as described here:

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/93717/325969.aspx#325969

    We use Perforce, so each developer would have a local copy in the workspace, not actually on the network.  My goal is for everything to be completely portable, ie: no absolute paths to anything.  A new developer would be able to install (just) CCS4, setup a few environment variables, get the latest out of P4 and build the project.  I have had some success using a mix of macros.ini and environment variables to accomplish this.  However, XDC tools has been a sticking point from CCS (command line builds don't seem mind the tools being wherever).

    Any further ideas?  I'm willing to hear other thoughts on accomplishing the desired level of version control as well.

    Thanks for your time.

  • 0 in reply to Richard Zuber
    TI__Expert 3550 points

    What version of XDCtools and CCS4 are you using?

    Regards

    Amit

  • 0 in reply to AmitMookerjee
    Prodigy 210 points

    Sorry, should have mentioned that in my original post:

    XDCTools 3.20.08.88

    CCS4 4.2.1.00004

  • 0 in reply to Richard Zuber
    TI__Expert 3550 points

    Richard,

    The procedure described above to discover new products should work for you. A screenshot showing the discovery of XDCtools 3.21.00.48-eng  over the network in the product discovery dialog is shown below. If the IDE detects a new product it will show a yellow marker next to it and the hover help will advise the user for a restart. Once you press the Apply button in the dialog another dialog will prompt for a restart of the IDE. After restarting the IDE, you should be able to use this new version of XDCtools.

     

    Did you see the same behavior in the UI when you were trying to detect your product? Is it possible to attach a screenshot of your product discovery dialog?

    Regards

    Amit

  • 0 in reply to AmitMookerjee
    Prodigy 210 points

    OK, I think I understand the issue.  When I tried to install the tools as you directed, they were never discovered:

    I had renamed the top level folder to something generic so that way it could simply be modified in version control as it was updated without changing the folder name.  By adding back in the path, the detection works properly:

    I guess I had assumed the top level directory name was arbitrary and not parsed by CCS.  In the back of my mind I thought the package.xdc compatibility key was used for versioning, but examining that file I see that is not the case.  Carefully reading the packaging primer again confirms this: http://rtsc.eclipse.org/docs-tip/RTSC_Packaging_Primer/Lesson_9.  I will say I'm still uncertain as to why it is disallowed... I could have a top level release that I don't put a version on (risking name collision).  Is it a requirement that releases be of the form PACKAGENAME_X?

    So from what I understand now, my thought of version controlling these files manually in this manner is not possible.  I will have to check in each individual version and link as needed.  Probably not a big deal, but not exactly what I had envisioned.  It should serve the purpose of keeping all developer machines in sync if part of our "start a new person" procedure is to have them uninstall all local tools and point their tool discovery path to their personal source control workspace version.

    Should I be concerned about the original error with the registry setting I posted about?

    Thank you for your time helping me out, I appreciate it.

  • 0 in reply to Richard Zuber
    TI__Expert 3550 points

    Hi Richard,

    Richard Zuber said:
    I had renamed the top level folder to something generic so that way it could simply be modified in version control as it was updated without changing the folder name.  By adding back in the path, the detection works properly:

    You should not change the top level folder name but you can have a top level  folder under which you can install different versions of XDCtools. If you mention the top level folder in the tool discovery path then the underlying products will be discovered as well.

    An example to make this clear.

    Assuming you have the following layout of XDCtools installations in your network folder

    N:\xdctools\

                       xdctools_3_20_07_86

                        xdctools_3_20_08_88

     

    Now if you add  N:\xdctools to your tool discovery path then CCS4 will discover all the underlying products. This is convenient for your team, since they do not have to change their tool discovery path every time a new release of XDCtools is installed in the folder. Also, at startup time CCS4 will search the existing tool discovery path for new products and  prompt the user for a restart if a new release is detected. 

    Also, you can follow the same pattern of product discovery for all RTSC based products like SYS/BIOS, IPC, XDAIS,Codec Engine etc..

    Richard Zuber said:
    I guess I had assumed the top level directory name was arbitrary and not parsed by CCS.  In the back of my mind I thought the package.xdc compatibility key was used for versioning, but examining that file I see that is not the case.  Carefully reading the packaging primer again confirms this: http://rtsc.eclipse.org/docs-tip/RTSC_Packaging_Primer/Lesson_9.  I will say I'm still uncertain as to why it is disallowed... I could have a top level release that I don't put a version on (risking name collision).  Is it a requirement that releases be of the form PACKAGENAME_X?

     We follow a naming convention that derives the top level folder name by appending the product version number  to the product name. In our initial implementation of product discovery we looked at the folder name to derive the version number. We have made this more extensible in later releases where a product can describe via eclipse extensions its product version. However for compatibility purposes we still follow the old discovery mode for XDCtools. In general products can have arbitrary top level folder name and the product discovery should do the right thing. The only requirement is that the eclipse folder should be in the top level directory of the product (take a look at xdctools_3_20_08_88/eclipse in your setup). Again this a product layout convention that we have formalized for all our products and out tools have been developed accordingly. In general it is not a good practice to edit any of the product folders as there maybe some software contracts that maybe broken.

    Richard Zuber said:
    Should I be concerned about the original error with the registry setting I posted about?

    No you are fine. This step is not required for CCSv4 users. The registry updates are required only for CCSv3 users and they have a slightly different installer that takes care of this issue. Thanks for pointing this out. I will edit the wiki to add this caveat.

    One thing I am concerned about after taking a look at your screenshot is that I see a yellow warning marker next to the discovered XDCtools product. This indicates that XDCtools eclipse plugins have not been loaded by the eclipse platform. Please ensure that you have copied all the files in the network folder (including the all important top level eclipse folder). 

    I would advise deleting this installation and doing a fresh install by using the installer. You can get the installer for XDCtools 3.20.08.88 here.

    Also, delete any other copies of XDCtools 3.20.08.88 that you have on your system.

    After installation is complete you can follow the above mentioned steps to discover the new product. If the product is installed correctly then you should not see the yellow warning marker next to the product in the product discovery dialog. Another way to confirm that your product is installed correctly is by looking at the help menu for the product.

    Navigate to Help -> Help Contents and you should see the help documentation for the latest installed version of  XDCtools. A screenshot showing the help docs for XDCtools 3.20.07.86 is shown below.

     

    Regards

    Amit

     

     

  • 0 in reply to AmitMookerjee
    Prodigy 210 points

    Amit,

    Thank you for your well thought out reply, I appreciate it.

    Richard Zuber