changing Qt version in CCSv5

Hi,

I am not familiar on the specifics of Qt and other third-party plugins, but since the Qt support in Eclipse/CCSv5 is entirely made with open source components a search on the internet may be of further help.

The Qt Eclipse project page lists its support up to release 4.6.1 and CDT 4.0. Since CCSv5 uses a newer version of CDT chances are this will work, but it is not guaranteed.

The project page above has install instructions, and the most relevant info can be found at the link Qt Eclipse Integration Documentation.

Hope this helps,

Rafael

Thanks,

Poking around there did get me to Help->Install New Software -> what is already installed -> configuration tab

There are entries for the CCS Windows->Preferences->Qt choices of Qt version, where I have added 4.7.4 and made it the default.

But there are a couple of others that look like they are set by the CCS managed build plugin.

I don't see any way to edit that configuration though, so maybe those paths are hard coded and I am stuck with them.

I should probably just go back to using QT Creator to build and test under ubuntu, then jsut qmake and make to cross compile for my target.

I'll post back if I find a workaround, but CCS is probably not worth the hassle for what I am trying to do.

Well, after digging around in the weeds of eclipse without finding anything, and researching eclipse plugin configuration online, I noticed instructions to run eclipse -clean when installing plugins for the first time.  This led me to think about how I run CCSv5, and I remembered that I found it needed to be started with the linux-devkit environment. Anyway, <TI-SDK-path>/linux-devkit/environment-setup sets a whole bunch of environment variables.  Unfortunately, its assumed that the QT installation is the one embedded in the SDK, so it will be a little tricky to sort out the Qt E.V.'s from the toolchain E.V.s

For that matter, it looks like this is possibly where I can change the toolchain.  Since I have to use code sourcery to build Qt (Qt build won't accept TI's tool chain), I might want to be consistent in building applications, although my understanding is that the TI toolchain differs very little, maybe only some improved code optimization for a few specific cases.

I don't know yet if hacking the environment will do what I want, and not sure when I will get around to trying it, but I thought I'd add a post about it in case anyone else is trying to do the same thing. (and so I can remember what I figured out down the road)

Hi,

Thanks for posting the details on your investigation. Although I don't have the devkit handy right now, your description on the devkit paths look correct.

Just to give you some additional hints on the use of the CodeSourcery toolchain, please check the page below:

http://processors.wiki.ti.com/index.php/How_to_create_GCC_projects_in_CCSv5

The TI toolchain and the TI Project Manager plugin do not generate linux-compatible code, therefore the page explains how to integrate any open-source toolchain and use the standard Eclipse Project Manager.

Regards,

Rafael

"The SDK libraries all in in a capital 'E"

It turns out that there is a QT_LIBINFIX that apprently can be set by -qtlibinfix passed to configure.

And hacking the linux-devkit environment-setup script to separate the path definitions for Qt stuff from the toolchain stuff mostly worked.

I ran into a small problem that I think was due to my renaming the directory that I built Qt 4.7.4 into, the old name still popped up in the makefile.

And I thought the MAKESPEC definitiion should point to the Qt source and not to the target-built Qt directory (which doesn't have the linux-TIarmv7-g++ mkspec).

Bottom line I was able to create a new Qt Gui project in CCSv5, build it, and run it on my target, using the Qt 4.7.4 target install that I cross-compiled and installed on the target.

And it worked.  So I might just be back in business with Code Composer.

Now where is that "verify" button???

Hi,

This thread was set as a "Discussion", therefore there are no Suggest/Verify Answer buttons.

Thanks again for sharing your findings. They will be very useful for other developers.

Regards,

Rafael