[swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

Jordan Rose jordan_rose at apple.com
Tue Mar 15 12:28:45 CDT 2016


What is a "debug build"? Is it one where testing is enabled? Where the optimization level is -Onone? (We've talked about having an -Odebug and/or -Oplayground at some point. Are those "debug builds"?) Is it one where asserts are not removed? (This can technically be controlled independently of -O, but we don't advertise the fact, and I'm not sure we even want that feature.)

Also, what is "config"? It doesn't mean anything to me on its own, which means I wouldn't know what else I can put besides "debug".

Jordan


> On Mar 14, 2016, at 11:57 , Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> https://gist.github.com/erica/d20639b409fe1b318c0e <https://gist.github.com/erica/d20639b409fe1b318c0e>
> 
> Feedback solicited. Thanks, -- Erica
> 
> Introducing a Debug Build Configuration Test
> 
> Proposal: SE-00XX
> Author(s): Erica Sadun <http://github.com/erica>
> Status: TBD
> Review manager: TBD
>  <https://gist.github.com/erica/d20639b409fe1b318c0e#introduction>Introduction
> 
> This proposal introduces a configuration test for debug builds.
> 
> This proposal was discussed on-list in the Introducing a Debug Build Configuration Test <applewebdata://FB8B7ABA-BA05-4EF3-A260-C9959FBA2814> thread.
> 
>  <https://gist.github.com/erica/d20639b409fe1b318c0e#motivation>Motivation
> 
> Developers are used to including code specific to debug builds in their projects. Having a debug configuration test is an industry standard option. Under the current version of Swift you must add a command-line flag using -D <#flag#> (e.g. -D debug) and test in-code (#if debug), there's no consistent system-supplied way to differentiate code meant only for debug builds.
> 
>  <https://gist.github.com/erica/d20639b409fe1b318c0e#detail-design>Detail Design
> 
> This proposal adds #if config(debug) to test for debug builds. 
> 
> #if config(debug)
>     // code for debug builds only
> #endif
>  <https://gist.github.com/erica/d20639b409fe1b318c0e#background>Background
> 
> Joe Groff writes, "We specifically avoided making debug/release an #if condition because we considered #if to be the wrong point at which to start conditionalizing code generation for assertions. Though the final executable image's behavior is unavoidably dependent on whether asserts are enabled, we didn't want the SIL for inlineable code to be, since that would mean libraries with inlineable code would need to ship three times the amount of serialized SIL to support the right behavior in -Onone, -O, and -Ounchecked builds. Instead, the standard library has some hidden helper functions, _isDebugAssertConfiguration, _isReleaseAssertConfiguration, and _isFastAssertConfiguration, which are guaranteed to be constant-folded away before final code generation." 
> 
>  <https://gist.github.com/erica/d20639b409fe1b318c0e#current-art>Current Art
> 
> Swift currently supports the following configuration tests:
> 
> The literals true and false
> The os() function that tests for OSX, iOS, watchOS, tvOS, and Linux
> The arch() function that tests for x86_64, arm, arm64, and i386
> The swift() function that tests for specific Swift language releases, e.g. swift(>=2.2)
>  <https://gist.github.com/erica/d20639b409fe1b318c0e#alternatives-considered>Alternatives Considered
> 
> There are no alternatives considered.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160315/6ddceb8d/attachment.html>


More information about the swift-evolution mailing list