• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 81 subscribers
  • Views 428 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/LAUNCHXL-F280049C: Spaces/bad formatting in the created dependency file (.pp) causing build error

Aditya Padmanabha
Expert 1440 points
Part Number: LAUNCHXL-F280049C

Tool/software: TI C/C++ Compiler

Hi,

I am building the executable outside Code Composer Studio. I am trying to use the dependency option (preproc_dependency or preproc_includes) of compiler to build the executable. Some of the files which I am referring is in the path with spaces (C:/Users/apadmana/AppData/Local/Temp/24664/ml_qQqq/w s/matlab/toolbox/target/supportpackages/tic2000/src/c28004xBoard_Realtime_Support.c). In the make file (C28x_Build.mk) I use transformed path for the same (C:/Users/apadmana/AppData/Local/Temp/24664/ml_qQqq/WS6813~1/matlab/toolbox/target/supportpackages/tic2000/src/c28004xBoard_Realtime_Support.c). 

  1. preproc_dependency option - The build process successfully creates the executable without any issues for the first build. But if I try to build the executable again it will fail with error message "gmake: *** No rule to make target `C:/Users/apadmana/AppData/Local/Temp/24664/ml_qQqq/w', needed by `c28004xBoard_Realtime_Support.obj'. Stop.". When I investigate further I find out that the dependency file created consists of .c file with the full path with spaces and all the related .h file with transformed pathwhich I am providing in the make file. Please refer to the sample c28004xBoard_Realtime_Support.pp file attached along with make file.
    1. Why does the dependency file created is taking the full path with spaces for only .c file when we provide transformed path in the make file? (The .h file is still using transformed path in dependency file)
    2. Why compiler does not add any escape sequence required for the paths?

  2. preproc_includes option - The build process successfully creates the executable without any issues for the first build. But if I try to build the executable again it will fail with error message "MW_c28xx_board.pp:1: *** missing separator.  Stop.". When I investigate further I find out that the dependency file created only all the related .h file with transformed path which I am providing in the make file but some issues with spacing and line endings which causes the build failure. Please refer to the sample MW_c28xx_board.pp file attached along with make file.
    1. Why the dependency file created has bad formatting that the gmake fails to recognize the line endings and the file generated has arbitrary spaces?

What is the solution for the above issues? I am not able to make use of dependency options to ensure the .obj files are properly generated and are updated based on updates for.c and .h files.

Compiler version used : ti-cgt-c2000_16.9.2.LTS

C28x_Build.zip

Thanks,

Aditya

  • 0
    TI__Guru**** 242275 points

    Regarding ...

    Aditya Padmanabha said:
    preproc_dependency option

    I agree the compiler should not, in the preprocessor output, emit a path or file name with a space in it.  Instead it should output what you call the transformed name.  Note this article from MicroSoft on this topic uses terms like short 8.3 alias or short name.  In those terms, if a long name ever has a space, the short name should be output instead. Thus, I filed CODEGEN-5623 in the SDOWP system to have this problem addressed.  You are welcome to follow it with the SDOWP link below in my signature.

    Regarding ...

    Aditya Padmanabha said:
    preproc_includes option

    The output from --preproc_includes is not intended to be used as input to make.  It is intended as a debugging tool.  If you don't understand just how some header file is included by some source file, you can look at this output to work that out.

    Thanks and regards,

    -George