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

Dave Abrahams dabrahams at apple.com
Fri Apr 8 13:07:51 CDT 2016

on Fri Apr 08 2016, Chris Bieneman <cbieneman-AT-apple.com> wrote:

> 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.

Awesome; care to take a crack at it? :-)

> The full CMake code from <clang>/CMakeLists.txt is:
>   "Append the version control system revision id to clang version spew" OFF)
>     # This macro will set SVN_REVISION in the parent scope
>     add_version_info_from_vcs(VERSION_VAR)
>   endif()
>     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


More information about the swift-dev mailing list