[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:
>
> 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
--
Dave
More information about the swift-dev
mailing list