• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 145 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280039: Keeping relative path in makefile

Hang Yang
Expert 3666 points

Part Number: TMS320F280039

Hi Experts,

My customer is using git to manage the codes and the project would be compiled on the server.

They want to use gamke command for compile and the gamke command only. As far as I know the makefile required by gmake is generated by the ecplyse scripts. Which means that if they don't use ecplyse script, they connont generate the makefile from the .project CCS, and they have to include the makefile itself to the git to the management.

The problem is, the makefile contains absolute path, especially for include paths within the proejct. 

image.png

This absolute path includes the project root, which may varies on different machines. It makes that makefile not applicate on other machines.

My questions is how to retain relative path in the makefile? 

Note that there is also absolute path for the complier tools, but this is ok for customer becuase is reasonable to align the tool environment on different machine. The tool path would be the same for different machine.

  • 0
    TI__Mastermind 33633 points

    Hi Hang,

    The CCS auto-generated makefile is not designed to be portable across machines. Rather than trying to force CCS to emit relative paths, the recommended approach is to replace the hardcoded absolute project-root paths with a makefile variable, then have each machine (or build server) define that variable locally.

    How TI Solves This in Their Own SDKs

    TI's SDK makefiles use a variable-based path strategy. All makefiles include a top-level imports.mak file that defines a single variable — ${SDK_INSTALL_PATH} — and every path in every makefile is expressed relative to that variable [1][2]. If tools are installed at non-default locations, you simply modify the paths in imports.mak [3]. The makefiles themselves are intentionally simple and readable, so you can inspect and adapt them directly [4].

    Your customer can follow the same pattern.

    Recommended Approach

    Step 1: Define a PROJECT_ROOT variable

    At the top of the makefile (or in a separate imports.mak-style file that the makefile includes), add:

    # Each developer/server sets this, or it's passed via environment variable
    PROJECT_ROOT ?= /default/path/to/project

    Step 2: Replace absolute project paths with $(PROJECT_ROOT)

    Find all hardcoded absolute include paths that reference the project root and replace them:

    # BEFORE (not portable):
    INCLUDES += -I/home/user1/workspace/myproject/include
    INCLUDES += -I/home/user1/workspace/myproject/src/drivers
    # AFTER (portable):
    INCLUDES += -I$(PROJECT_ROOT)/include
    INCLUDES += -I$(PROJECT_ROOT)/src/drivers

    Step 3: Keep tool paths as-is

    As your customer noted, compiler/tool paths can remain absolute since those are standardized across machines.

    Step 4: Set PROJECT_ROOT per machine

    Each developer or build server defines the variable in one of these ways:

    Method
    Example
    Environment variable
    export PROJECT_ROOT=/home/server/builds/myproject
    Command-line override
    gmake PROJECT_ROOT=/home/server/builds/myproject
    Local imports file (git-ignored)
    Create local.mak with the definition; .gitignore it

    The ?= syntax in the makefile means the variable is only used as a fallback if not already set externally.

    Step 5: Commit the modified makefile to git

    Once the absolute paths are replaced with $(PROJECT_ROOT), the makefile is fully portable and safe to version-control.

    Important Consideration

    Since CCS regenerates the makefile from .project/.cproject files each time you use the Eclipse-based build, any manual edits to the makefile will be overwritten if someone later builds from the CCS GUI. Your customer should treat the makefile as a standalone, manually-maintained build artifact once they commit it to git — not something that gets regenerated from CCS. This is a one-time migration: extract the makefile from CCS, refactor the paths, and manage it independently going forward.

    If the project configuration changes (new source files, new include paths, changed compiler flags), those changes need to be reflected manually in the committed makefile rather than relying on CCS to regenerate it.

    Sources: (Note - while not C2K devices, the SDK makefile documentation is still relevant here)

    1. TI MCU+ SDK Makefile Build - AM243X
    2. TI MCU+ SDK Makefile Build - AM64X
    3. TI Motor Control SDK Makefile Build - AM243X
    4. TI Industrial Comms SDK Makefile Build - AM243X

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Expert 3666 points

    Hi Fleenor,

    Seems that makefile is not the only file that contains absolute path, the subdir_rules.mk and subdir_vars.mk also contains absolute paths. Do you recommend changing these files too? If so how to do it?

    Regards,

    Hang

  • 0 in reply to Hang Yang
    TI__Mastermind 33633 points

    Hi Hang,

    Yes — apply the same $(PROJECT_ROOT) variable substitution to subdir_rules.mk and subdir_vars.mk. These files are part of the same CCS-generated build system and will contain absolute paths just like the main makefile [1]. The approach is identical for all of them.

    How to Modify subdir_rules.mk and subdir_vars.mk

    subdir_vars.mk typically defines source file lists and include paths per subdirectory. Replace any absolute project-root paths with $(PROJECT_ROOT):

    # BEFORE:
C_SRCS += /home/user1/workspace/myproject/src/main.c
INCLUDES += -I/home/user1/workspace/myproject/include
# AFTER:
C_SRCS += $(PROJECT_ROOT)/src/main.c
INCLUDES += -I$(PROJECT_ROOT)/include
    subdir_rules.mk typically defines compilation rules (how to build .obj from .c for each subdirectory). Apply the same substitution to any absolute paths referencing the project root:
    # BEFORE:
/home/user1/workspace/myproject/Debug/src/%.obj: /home/user1/workspace/myproject/src/%.c
$(CC) $(CFLAGS) ...

# AFTER:
$(PROJECT_ROOT)/Debug/src/%.obj: $(PROJECT_ROOT)/src/%.c
$(CC) $(CFLAGS) ...

    Ensure the Variable Is Available to All Files

    Since the main makefile includes subdir_rules.mk and subdir_vars.mk, define PROJECT_ROOT at the top of the main makefile (or in a shared imports.mak that gets included first). The variable will then be available when make processes the sub-files [2].

    # Top of makefile (or imports.mak included at the top):
PROJECT_ROOT ?= /default/path/to/project

-include subdir_vars.mk
-include subdir_rules.mk

    Important Reminders

    • All these files are regenerated by CCS if someone builds from the GUI. Once you commit them to git with the variable-based paths, treat them as manually maintained — do not rebuild from CCS or your edits will be overwritten [1].
    • Only replace project-root paths. Leave compiler/tool paths absolute, as your customer already agreed those are standardized across machines.
    • Check for other .mk files (e.g., objects.mk, sources.mk) that CCS may have generated — they could also contain absolute paths and should be treated the same way.

    To help refine this recommendation, it would be helpful to know:

    • Whether your customer plans to ever use the CCS GUI build in parallel with the command-line build (which would cause regeneration conflicts)
    • Whether there are additional auto-generated .mk files beyond subdir_rules.mk and subdir_vars.mk in your specific project that also contain absolute paths
    1. TI AM13x Academy - CCS Build System Files
    2. TI MCU+ SDK Makefile Build - AM243X

    Best Regards,

    Zackary Fleenor