Tricks for including Build ID?

General JUCE discussion
1

Hi,

Has anyone got any suggestions for a CMake-based JUCE project, to include the current git hash as a Build ID in the project - the idea is so that we can easily recognize the latest commit of the project in the version.

I’ve looked at adding a hash to the VERSION file, but I’d kind of like something a bit more future-proof, so we can keep pace with whatever CMake changes occur with JUCE in the future.

In other words, we want to include the output of this command in a string somewhere - in JuceHeader.h? - in order to identify builds easily in the future:

 git rev-parse --short HEAD

Is there a ‘proper’ place to put this in our CMakeLists.txt - or maybe this would be a cool feature to add to future JUCE versions’ CMake scripts, somehow?

2

I read both the version number and the latest hash as follows:

find_package(Git)

if (GIT_EXECUTABLE)
    # Generate a git-describe version string from Git repository tags
    execute_process(
            COMMAND ${GIT_EXECUTABLE} describe --tags --abbrev=0
            OUTPUT_VARIABLE GIT_DESCRIBE_VERSION
            RESULT_VARIABLE GIT_DESCRIBE_ERROR_CODE
            OUTPUT_STRIP_TRAILING_WHITESPACE
    )
    if (NOT GIT_DESCRIBE_ERROR_CODE)
        set(FOOBAR_VERSION ${GIT_DESCRIBE_VERSION})
    endif ()
    execute_process(
            COMMAND ${GIT_EXECUTABLE} log -1 --format=%h
            OUTPUT_VARIABLE GIT_CURRENT_HASH
            RESULT_VARIABLE GIT_HASH_ERROR_CODE
            OUTPUT_STRIP_TRAILING_WHITESPACE
    )
    if (NOT GIT_HASH_ERROR_CODE)
        set(FOOBAR_HASH ${GIT_CURRENT_HASH})
    endif ()
endif ()

if (NOT DEFINED FOOBAR_VERSION)
    set(FOOBAR_VERSION 0.0.0)
    message(WARNING "Failed to determine VERSION from Git tags. Using default version \"${FOOBAR_VERSION}\".")
endif ()
if (NOT DEFINED FOOBAR_HASH)
  set(FOOBAR_HASH "0000000")
  message(WARNING "Failed to determine HASH from Git logs. Using default hash \"${FOOBAR_HASH}\".")
endif ()

string(REPLACE "v" "" FOOBAR_VERSION_WITHOUT_V "${FOOBAR_VERSION}")

add_definitions(-DZLEQUALIZER_CURRENT_VERSION="${FOOBAR_VERSION_WITHOUT_V}")

add_definitions(-DZLEQUALIZER_CURRENT_HASH="${FOOBAR_HASH}")
1 Like
3

You can just pass this as an argument to CMake.

cmake -G ... -D GIT_TAG="1.0.3"

Then in the CMake File you can will have access to that argument, for example you can do:

target_compile_definitions (MyPlugin PUBLIC GIT_VERSION=${GIT_TAG})

To have it avaliable as a macro in your code.

1 Like
4

Thanks folks, those are both really great answers - I like the succinct nature of @eyalamir 's approach, but I’m going to go ahead and incorporate @zsliu98 's CMake code, as that allows for a bit more flexible approach in different build scenarios.

Might have to see if this can be pushed upstream to PampleJuce/JUCE official, also. Just seems to me to be so useful to be able to click the plugin version string and get the build hash in the future …

5

I think something like that totally belongs in user space and has no place in JUCE.

But in your build scripts - why not? You can make it a CMake function and expose it across multiple projects (just don’t use something like add_definitions since it’s global, and you might have multiple git repos).

6

Oh, I saw it more of an extension of the VERSION file mechanism, just as an added value for service/support requests, when chasing down bugs - but yeah … its no problem either way to just add the code to include the Build ID in my own CMake scripts.