smanders / externpro

build external projects with cmake
MIT License
13 stars 12 forks source link

revision.cmake issues #233

Closed smanders closed 4 years ago

smanders commented 5 years ago

developer reported the following on 2018-10-02:

CMake Error at C:/Program Files/externpro 18.08.4-vc140-64/share/cmake/revision.cmake:31 (string):
string sub-command REPLACE requires at least four arguments.
Call Stack (most recent call first):
C:/Program Files/externpro 18.08.4-vc140-64/share/cmake/xpfunmac.cmake:1236 (include)
Shared/make/toplevel.cmake:33 (xpGenerateRevision)
CMakeLists.txt:5 (include)

CMake Error at C:/Program Files/externpro 18.08.4-vc140-64/share/cmake/revision.cmake:32 (if):
if given arguments:

"STREQUAL" "master"

Unknown arguments specified
Call Stack (most recent call first):
C:/Program Files/externpro 18.08.4-vc140-64/share/cmake/xpfunmac.cmake:1236 (include)
Shared/make/toplevel.cmake:33 (xpGenerateRevision)
CMakeLists.txt:5 (include)

Configuring incomplete, errors occurred!

See also "C:/dev/Vantage/_bld/CMakeFiles/CMakeOutput.log".
smanders commented 5 years ago

IIRC this issue is when the path to git changes and the cmake-cached location is no longer valid (a new/clean run of cmake handles the new location of git without any problem)

smanders commented 4 years ago

another issue: revision not showing as expected for RELEASE_BRANCH

background: a top-level cmake file for a project that wants to generate a Revision.hpp file will call

xpGenerateRevision(RELEASE_BRANCH master) # ${CMAKE_BINARY_DIR}/Revision.hpp

xpGenerateRevision https://github.com/smanders/externpro/blob/20.02.1/modules/xpfunmac.cmake#L1328-L1340

function(xpGenerateRevision)
  set(oneValueArgs SOURCE_DIR RELEASE_BRANCH)
  cmake_parse_arguments(P "" "${oneValueArgs}" "" ${ARGN})
  if(NOT DEFINED P_SOURCE_DIR)
    set(P_SOURCE_DIR ${CMAKE_SOURCE_DIR})
  endif()
  if(NOT DEFINED P_RELEASE_BRANCH)
    set(P_RELEASE_BRANCH master)
  endif()
  set(xpSourceDir ${P_SOURCE_DIR})
  set(xpRelBranch ${P_RELEASE_BRANCH})
  include(${xpThisDir}/revision.cmake)
endfunction()

and the relevant section from revision.cmake https://github.com/smanders/externpro/blob/20.02.1/modules/revision.cmake#L24-L39

  # xpRelBranch (release branch): date yyyymmdd-gitdescribe (20120518-gitdescribe)
  # other branches: user-branch-gitdescribe (smanders-padawan-gitdescribe)
  execute_process(COMMAND ${GIT_EXECUTABLE} name-rev --name-only HEAD
    WORKING_DIRECTORY ${xpSourceDir}
    OUTPUT_VARIABLE refsBranchName
    OUTPUT_STRIP_TRAILING_WHITESPACE
    )
  string(REPLACE "remotes/origin/" "" branchName ${refsBranchName}) # submodules need this
  if(${branchName} STREQUAL ${xpRelBranch})
    string(TIMESTAMP ymd %Y%m%d)
    set(revisionPrefix "${ymd}")
  elseif(UNIX)
    set(revisionPrefix "$ENV{USER}-${branchName}")
  else()
    set(revisionPrefix "$ENV{USERNAME}-${branchName}")
  endif()

so it should behave such that if the RELEASE_BRANCH is master, the result of git name-rev --name-only HEAD should match (STREQUAL) master and the revision should be of the form: yyyymmdd-gitdescribe (20120518-gitdescribe) and not user-branch-gitdescribe (smanders-padawan-gitdescribe)

however, currently on a master branch (and when RELEASE_BRANCH is master), we are seeing Revision.hpp look like:

#define SCM_REV_NUM "smanders-tags/v3.0.3.0-v3.0.3.0"

only on Windows and only recently, which seems to be a result of newer versions of git (on Windows)

and sure enough, the git name-rev --name-only HEAD results seem to have changed and no longer produce the expected master

$ git name-rev --name-only HEAD
tags/v3.0.3.0
smanders commented 4 years ago

a quick search on the internet suggests the following

$ git rev-parse --abbrev-ref HEAD
master

and this produces the expected master

smanders commented 4 years ago

I'm not going to address the first revision.cmake issue https://github.com/smanders/externpro/issues/233#issue-446354973 reported here, since it's slightly difficult to reproduce (uninstall git, install to a different location?, especially with the unknowns of CyberArk in the mix...)

will mark this as a known-issue -- with the work-around being to start from a clean out-of-source build directory

smanders commented 4 years ago

completed with commits to dev branch referenced above and known-issue (and work-around) identified