CCS/CODECOMPOSER: command line projectImport not working

Erich,

I tried a few similar projectImport commands with CCSv10 and did not have any issues.

Could you capture the output from executing that command and attach it here?

Also what are the contents of the .\Source\bootloader-starterware directory? Does it contain a CCS project or makefile project?

The help text:

PS C:\src\MyProject> C:\ti\ccs1000\ccs\eclipse\eclipsec.exe -noSplash -data "C:\src\_workspaces\workspace_v10" -application com.ti.ccstudio.apps.importProject -ccs.location .\Source\bootloader-starterware\
Usage:
        eclipsec -noSplash -data "<workspace_dir>"
                -application com.ti.ccstudio.apps.importProject
                -ccs.location <path> [<options>]

where options include:
        -ccs.location <path>
                Absolute or relative path to the location containing the project.
                Relative paths will be assumed to be relative to the working directory.

        -ccs.device <id>
                The device-variant ID. Applicable only when '-ccs.location' flag resolves to a .projectspec file.

        -ccs.definePathVariable <name> <value> [@scope (global|project)]
                Defines the given path-variable for resolving portable linked file paths (optional)
                (also defines a global build-macro with the same name and value).
                Optionally, specify the scope (defaults to 'global').

        -ccs.copyIntoWorkspace
                Copy project folder and contents into the workspace directory (optional).
                Defaults to 'false'.

        -ccs.overwrite
                Forces overwrite of existing file-system resources (optional).

        -ccs.renameTo
                Rename the imported project to the specified name.

        -ccs.autoBuild
                Performs an incremental build on the imported/created project (optional).

        -ccs.autoImportReferencedProjects
                If 'true', an attempt is made to automatically import any referenced projects found in the same parent directory as the main project.

        -ccs.autoRenameReferencedProjects
                If 'true', and iff the '-ccs.renameTo' flag is present, any imported referenced projects will also be renamed automatically.

        -ccs.referencedProjectSearchDirectory
                Directory to search for referenced projects. Applicable only when '-ccs.autoImportReferencedProjects' flag is present.

        -ccs.captureCopiedFileOrigins
                Capture the original locations of all resources copied into the project during the import. These will be captured into a text file named 'copiedFileOrigins.txt'.

        -ccs.captureProjectspecApplicability
                Capture the list of devices that the imported projectspec is applicable to. These will be captured into a text file named 'projectSpecApplicability.txt'.

        -ccs.args <file>
                File containing any extra arguments (optional).

        -ccs.help
                Print this help message.

PS C:\src\MyProject>

The contents of .\Source\bootloader-starterware\:

.ccsproject
.cproject
.gitignore
.launches/
.project
.settings/
AM437x.lds
am43xx_boot.lds
binary/
board/
bootloader/
build/
dal/
Debug/
device/
docs/
examples/
include/
library/
Makefile
Rules.make
soc/
startup_ARMCA9.S
tools/
utils/

Hmm, interesting... a different result:

c:\src\MyProject>C:\ti\ccs1000\ccs\eclipse\eclipsec.exe -noSplash -data "C:\src\_workspaces\workspace_v10" -application com.ti.ccstudio.apps.importProject -ccs.location .\Source\bootloader-starterware\

--------------------------------------------------------------------------------
Importing project from 'C:/src/MyProject/Source/bootloader-starterware/'...


Done!

c:\src\MyProject>

What would cause it to fail when executed via PowerShell?

Erich Schroeter said:

What would cause it to fail when executed via PowerShell?

PowerShell can by quite finicky compared to the old cmd shell. I've had various compatibility issues between the two. Clearly the CCS command-line project functionality was tested from a cmd shell but not PowerShell. I can reproduce the issue on PowerShell as well. I can't seem to figure out why. In the meantime, you can use the cmd shell while we investigate.

Thanks

ki 

Oh, that's weird, but it fixed the issue. Thanks!

It is indeed strange. There is something about the way parameters are handled in PowerShell, which differ from the old DOS cmd window. I don't quite understand it, I'm quite a PowerShell novice while I've been using DOS cmd window for decades. I'll continue to poke around at this for more clarity. Thanks for bringing this to our attention.

ki