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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
