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.

CCS/MSP430FR5969: Storing a symbol value before building?

Part Number: MSP430FR5969


Tool/software: Code Composer Studio

I'm trying to grab the git tag information for my code before I compile it. In a command shell, I can just run the following in order to store the information in an environment variable:

git describe > temp.txt
set /p VERSION_NUMBER=<temp.txt
del temp.txt

Those steps executed fine in the compilation, but when it gets to building main.c where VERSION_NUMBER is referenced, the symbol is still undefined. What is the correct way to set this up? Will these steps get executed in the generated makefile, or will they get executed in a shell which closes before the compiler is called? Here is how I put the commands into the pre-build steps:

 

  • Paul Shepherd17 said:
    Will these steps get executed in the generated makefile, or will they get executed in a shell which closes before the compiler is called?

    The latter is correct, so the variable will not be known to CCS or the compiler just by this pre-build step. You could use setx, however since that only applies to new shells, I found that it is only known to CCS after a restart. This page shows how you can associate a CCS variable with a C source file variable, but the example here uses hard-coded values for the CCS variables.

    Another alternative may be to write a script that writes this variable to a header file (as a #define) and call that script in the pre-build step. The header file could then be included as part of the build. 

  • Hi AartiG,

    I have been working on the second option... creating a bash script which parses the 'git describe' return string and generates version.h file to be included, but I realized why this is generally discouraged. The risk is that if someone grabs a version.h file, and does not update it before building, then all of the version info is wrong. 

    Upon further reading, it seems that the automated makefile generation is a feature of the underlying eclipse IDE, and that there is no option to insert additional statements into this makefile. The only option appears to be fully automated or fully manual. I think converting our codebase over from automated to manual makefile will make the most sense.

    FWIW, we are trying to implement this system on our main build server, but I have to have an equivalent that I can run on my workstation inside CCS. taking the eclispe makefile out of the loop seems like it will fix other inconsistencies between my workstation and our build server as well. (Link to incorporating version info in SW: https://embeddedartistry.com/blog/2016/10/27/giving-you-build-a-version )

    Thanks,

    Paul

  • Paul Shepherd17 said:
    The risk is that if someone grabs a version.h file, and does not update it before building, then all of the version info is wrong. 

    Since the pre-build step always run before the main build, if this step touches/updates the version.h file would that not ensure they are getting the correct file?

    Paul Shepherd17 said:
    Upon further reading, it seems that the automated makefile generation is a feature of the underlying eclipse IDE, and that there is no option to insert additional statements into this makefile.

    This is mostly true. However, there is some capability to extend the makefile behavior that comes from Eclipse (and not used by TI). Please see this article for more information. You could try looking into whether the makefile.init will serve the purpose.

    Paul Shepherd17 said:
    I think converting our codebase over from automated to manual makefile will make the most sense.

    A manual makefile certainly does give you more control and flexibility. Ultimately you will have to make the decision on what will work best for your environment. 

  • Hi Aarti,

    Your link to the makefile.init info is the silver bullet. That is perfect!

    To your first point, we can try to get everyone to use a consistent CCS project setup, but cannot guarantee it. Putting this info into the makefile is a more bulletproof solution, because, as I said, if the build version information goes out of scope, it will error out, instead of possibly picking up old build info from a file on disk.

    Thanks,

    Paul

  • Hi Aarti,

    One more follow-up to close the loop. We WERE able to get everything working, using the makefile.init, and pushing the symbolic definitions into the compilation step via the GEN_OPTS__FLAG variable, which is defined before the makefile.init is included. Here is the snippet of makefile.init which runs on windows. It is enclosed inside an if statement to detect the platform, and there is a similar version for our linux build server.

    version := $(subst -, ,$(shell git describe --long --dirty --tags))
    COMMIT := $(strip $(word 3, $(version)))
    COMMITS_PAST := $(strip $(word 2, $(version)))
    DIRTY := $(strip $(word 4, $(version)))
    ifneq ($(COMMITS_PAST), 0)
            BUILD_INFO_COMMITS := .$(COMMITS_PAST)
    endif
    ifneq ($(DIRTY),)
            BUILD_INFO_DIRTY :=+
    endif
    
    VERSION_TAG :=$(strip $(word 1, $(version)))
    BUILD_INFO := $(COMMIT)$(BUILD_INFO_COMMITS)$(BUILD_INFO_DIRTY)
    BUILD_DATE := $(shell date /T), $(shell time /T)
    BUILD_MACHINE := $(shell echo %username%)@$(shell hostname)
    $(info Build Time: $(BUILD_DATE))
    $(info Build Version: $(VERSION_TAG))
    $(info Build Info: $(BUILD_INFO))
    
    GEN_OPTS__FLAG += --define=VERSION_TAG="\"$(VERSION_TAG)\"" \
                      --define=VERSION_BUILD_INFO="\"$(BUILD_INFO)\""\
                      --define=VERSION_BUILD_MACHINE="\"$(BUILD_MACHINE)\""\
                      --define=VERSION_BUILD_DATE="\"$(BUILD_DATE)\""
    

    Thanks again for the help on the ins and outs of the eclipse makefile generation!

    Paul

  • Paul,

    Thank you for the follow-up and for posting details about your solution. This will definitely be a helpful reference for other users looking for something similar.

**Attention** This is a public forum