• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1892 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler: gmake is very slow to compile when on company network

Gabor Hencz22
Prodigy 80 points

Tool/software: TI C/C++ Compiler

Hi!

We've been experiencing a very strange behavior lately. This problem persists in CCS V7 and V8, and even if using the TI compiler tools from the command line.

During my research I found that when my PC is connected to the Siemens local network, the build process becomes extremely slow, every operation takes around 30 seconds to complete (to build one file, or to clean the project, etc.). If the PC does not have a network connection, or it is connected to a regular network, everything is working fine.

I also have a regular Eclipse with GNU ARM tools, which works fine in all circumstances. Using Sysinternals Process Explorer I noticed that the GNU ARM toolchain uses the MinGW sh.exe for the shell operations (echo, compiler commands, etc.), while TI's gmake uses the windows cmd.exe. When on company network, the cmd.exe processes launched by gmake.exe look like they are taking too much time to complete, blocking the whole build process.

Do you have any ideas how to investigate the issue further? I'm suspecting a company policy / company installed process in the background, but I don't know how to find the culprit. Telling gmake to use and other shell might be an option, but specifying SHELL = sh.exe in the makefile does not seem to change anything...

  • 0
    TI__Guru**** 173310 points

    Gabor Hencz22 said:
    I also have a regular Eclipse with GNU ARM tools, which works fine in all circumstances. Using Sysinternals Process Explorer I noticed that the GNU ARM toolchain uses the MinGW sh.exe for the shell operations (echo, compiler commands, etc.), while TI's gmake uses the windows cmd.exe. When on company network, the cmd.exe processes launched by gmake.exe look like they are taking too much time to complete, blocking the whole build process.

    One way to test this theory could be to set up CCS to use the make utility from the GNU toolchain instead of the default gmake in CCS and see how it impacts build time. This page describes how you can change the make utility in the project's build properties.

  • 0 in reply to AartiG
    Prodigy 80 points

    AartiG said:
    One way to test this theory could be to set up CCS to use the make utility from the GNU toolchain instead of the default gmake in CCS and see how it impacts build time. This page describes how you can change the make utility in the project's build properties.

    Doing the steps in the link is not enough, as I discovered, because CCS puts 

    SHELL = cmd.exe
RM := DEL /F
RMDIR := RMDIR /S/Q

    into the auto-generated makefiles. Disabling makefile auto-generation and removing the above lines from all the makefiles did the trick, the build process works like a charm with the minGW shell (sh.exe). It even works fine with TI's gmake when the shell is not forced to be CMD.exe.

    So it appears that something shady is going on with CMD when the PC is on the company network. I'll try to contact my local IT department about this.

    Meanwhile, is it possible in CCS to set options for the makefile autogeneration? If CCS did not put the quoted lines into the generated makefile, that would be a viable workaround...

  • 0 in reply to Gabor Hencz22
    TI__Guru**** 173310 points

    Gabor Hencz22 said:
    Meanwhile, is it possible in CCS to set options for the makefile autogeneration?

    Sorry, the only way is to disable the automatic makefile generation and then manually edit the makefiles, as you have already discovered.

  • 0
    TI__Guru**** 173310 points

    Please see this post for more details and workaround that helped that user.