[swift-dev] Why are we re-linking?

[Chris Bieneman]

In Clang this is handled by having a CMake option control whether or not the SCM revision is embedded in the binary (CLANG_APPEND_VC_REV). Clang defaults the option to 'Off' so that engineering workflows don't need to override it, but it is frequently enabled on bots and in distributions.

The build system and code in the compiler to do this is very simple, and could likely be applied to Swift.

The full CMake code from <clang>/CMakeLists.txt is:

option(CLANG_APPEND_VC_REV
  "Append the version control system revision id to clang version spew" OFF)
if(CLANG_APPEND_VC_REV)
  if(NOT SVN_REVISION)
    # This macro will set SVN_REVISION in the parent scope
    add_version_info_from_vcs(VERSION_VAR)
  endif()

  if(SVN_REVISION)
    add_definitions(-DSVN_REVISION="${SVN_REVISION}")
  endif()
endif()

-Chris

> On Apr 7, 2016, at 2:01 PM, Chris Lattner via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>> On Apr 6, 2016, at 11:08 AM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
>> 
>> I imagine it's because your git hash has changed, which is used in the --version output for swiftc. I'm not sure how to avoid that cost entirely, but we could add a CMake option to not do it (which you could set locally), and we could probably move it to a library that isn't used by most of those tools (so that we're only re-linking swiftc).
> 
> Could we move the hash to be a text file stored next to the executables in the installdir?  That way the text file gets updated, but not the binaries?
> 
> -Chris
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev