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.

How can CCS V5 command line build support the relative project path

Other Parts Discussed in Thread: CCSTUDIO

Hi,

I have read the existing CCS V5 command line build discussion, but all of them will try to use the local workspace to build the existing project name.

As we know that the CCS V5's project setting can support the relative path, but the workspace dont.

So we can only store the project setting in the network server of the version control tool, so every team member can import the project their local workspace without problem.

And we need the eclipse original command line build support as below:

eclipse.exe -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data %workSpaceDir% -import %projectDir% -build all

to import the project from the project path to a workspace path dynamically.

Can ccsv5 do that?

B&R
tony 

  • Hi Tony,

    I dont know if I understand your question correctly... but if you create a project in CCS V5 you can also store the generated makefiles. Then you dont need to call eclipse.exe (...) to build the project but call gmake directly to build via makefiles. Main advantage of this is that you dont need an eclipse workspace locally on a PC in order to be able to build the CCS project from command line.

    In my case I can store my project at any location and build it from there. I have everything checked into a subversion/source code control repository and check the sources out on different PCs into different locations. I have an environment variable that tells me the installation path of CCS, so that I can locate gmake...

    bye,

    Thomas

  • Tony,

    I'm not sure if I understand your question clearly either, but the first thing I wanted to point out is that it appears you are using the standard Eclipse CDT headless build command. Could you try using the CCS headless build commands instead? They are documented here: http://processors.wiki.ti.com/index.php/Projects_-_Command_Line_Build/Create

    If this page does not help answer your question, please reply with additional details as to what you are looking to do.

  • Hi Thomas,

    Thanks for your reply!

    I know that by using the CCS generated make files, we can do the command line build.

    The problem is that our software have a lot of folder levels and folders, to use the gmake command line build,

    we have to go to each sub folder and add the generated make files to the version control data base one by one for both Debug and Release config.

    If your source folder structure has any change, you have to add/remove/change the corresponding make files also.

    That is why I  try to find a way to use the CCS project  to do the command line build, but it seems that CCS v5 's project command line build only support

    the project name existing in the local workspace, but not the project folder which may contain the project from the version control server.

    B&R

    tony

  • Hi AartiG,

    As I said  it seems that CCS v5 's project command line build only support

    the project name existing in the local workspace,

    But if the option "-ccs.projects " was followed by a the project folder

    which may contain the project from the version control server, do not exist in the local work space,

    the project build will not start.

    For example, you run the following command line, D:\workspaceTmp is a empty work space:

    c:\ti\ccsv5\eclipse\eclipsec.exe -nosplash -data D:\workspaceTmp -application com.ti.ccstudio.apps.projectBuild -ccs.projects d:\projects\Venus_tmp\CCB_DSP\CCS_project\BasicSystem


    The screen log was as below 

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    CCS headless build starting... [Thu Jun 14 17:03:16 GMT+08:00 2012]
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

    ================================================================================
    Pre processing...


    !WARNING: Project 'd:\projects\Venus_tmp\CCB_DSP\CCS_project\BasicSystem' was not found in the workspace! Ignoring...
    NOTE: use the '-ccs.autoImport' argument to automatically import projects found in the workspace root directory.


    ================================================================================
    Building...

    ================================================================================
    CCS headless build complete!

    If you check the folder D:\projects\Venus_tmp\CCB_DSP\CCS_project\BasicSystem, nothing was generated!

    B&R

    tony

  • Tony,

    OK, I think I understand better now. You are correct in that the projectBuild expects the "name" of the project and not the "location" of the project. You should first import the project into the workspace before building it. The projectImport command can be used to import projects into the workspace prior to building them. Give this a try and let us know how it goes.

  • Hi AartiG ,


    When I use the projectImport command to  import projects into the workspace prior to building them, for some project it works.

    But for the project in which some file folder has the resource filter set to skip some of their sub folders, the following eclipse error message will be generated.

    The result was that the unwanted sub folder will be taken into account by the compiler, and the build will fail.

    c:\ti\ccsv5\eclipse\eclipsec.exe -nosplash -data workspaceTmp -application com.ti.ccstudio.apps.projectBuild -ccs.projects InfrastructureLib -ccs.configuration Release_28346 -ccs.buildType full

    org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.ui.ide was unable to load class org.eclipse.ui.internal.ide.misc.FileInfoAttributesMatcher.
    at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:194)
    at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:176)
    at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
    at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
    at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
    at org.eclipse.core.internal.resources.FilterDescriptor.createFilter(FilterDescriptor.java:76)
    at org.eclipse.core.internal.resources.Filter.match(Filter.java:44)
    at org.eclipse.core.internal.resources.Filter.filterExcludes(Filter.java:139)
    at org.eclipse.core.internal.resources.Filter.filter(Filter.java:92)
    at org.eclipse.core.internal.resources.Resource.filterChildren(Resource.java:2123)
    at org.eclipse.core.internal.resources.Resource.filterChildren(Resource.java:2085)
    at org.eclipse.core.internal.localstore.UnifiedTree.getLocalList(UnifiedTree.java:351)
    at org.eclipse.core.internal.localstore.UnifiedTree.addChildren(UnifiedTree.java:139)
    at org.eclipse.core.internal.localstore.UnifiedTree.addNodeChildrenToQueue(UnifiedTree.java:245)
    at org.eclipse.core.internal.localstore.UnifiedTree.accept(UnifiedTree.java:111)
    at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.java:920)
    at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:904)
    at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshRoot(FileSystemResourceManager.java:951)
    at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:897)
    at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1657)
    at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:167)
    at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
    Caused by: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.ui.ide (282).
    at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:122)
    at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:462)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
    at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:345)
    at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1207)
    at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174)
    ... 21 more
    Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start() of bundle org.eclipse.ui.ide.
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:734)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
    at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
    at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
    at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
    at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268)
    at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
    ... 33 more

    B&R

    tony

  • Hi,

    Should be this problem a bug of application com.ti.ccstudio.apps.projectBuild ?


    B&R

    tony

  • Hi Tony,

    I cannot reproduce this issue on CCS build 5.2.0.00069.  Could you please check the version of CCS you are using (it is shown in the Help > About dialog).  

    Thanks,

    - Baltasar

  • Hi Baltasar,

    Thanks for your reply.

    After updated to CCSv5.2, my issue was solved !

    B&R

    tony

  • followup:

    it is important to mention that the generated makefiles contain absolute paths. So if you try to build on a different location the wrong sources will be used. I find using generated makefiles dangerous to get strange behaviour because source files are used that one does not expect.

    It seems that the way is to create a portable project and import it in an empty CCS workspace (use an empty directory). With that the relative path information will be correct. As you posted, there is documentation here:
    http://processors.wiki.ti.com/index.php/Projects_-_Command_Line_Build/Create
    http://processors.wiki.ti.com/index.php/Creating_portable_projects_in_CCSv5

    It seems that a CCS workspace is more a storage for temporary files than something bound to a project. And that you can delete it between the builds. I thought that it has to be created first before you can build but it can be created by just importing an existing project.

    bye,

    Thomas