Along the lines of what Jordan is saying, I don't think there even is a such thing a unifying definition of "debug build". Even your definition for "my people" is a collection of build settings.
The definition of "asserts can fire" is also problematic. Maybe if tied specifically to Swift's asserts, but honestly, Swift's asserts, as they are, are simply not sufficient for everyone's development model. Here's an real example: I have a set of test automation that I want to ensure works. However, running this automation with a blocking assert is not what I want. Instead, I've created a mechanism for asserts, configurable at runtime, for the way in which those asserts are handled. During automation, I want those asserts to simply log, but code execution is not halted. During my normal dev cycle though, I want those asserts to be raised immediately so the developer sees the error and can chose to investigate or ignore the assert. The proposal seems to be trying to simplify something that is actually much more complicated in the wild. All that said, there is a feature that I think your proposal is hinting towards: the ability to define named configs from set of flags and compiler options (essentially, the ability to define your scheme in a Swift-friendly way). This feature would need coordination across the SwiftPM project as well though so you could define "MYCONFIG" as setting flags A-E, and likely other configuration settings. Then you would have the net of your proposal: #if config(MYCONFIG) #endif -David -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Erica Sadun via swift-evolution Sent: Tuesday, March 15, 2016 11:20 AM To: Jordan Rose <[email protected]>; Dmitri Gribenko <[email protected]>; Joe Groff <[email protected]> Cc: swift-evolution <[email protected]> Subject: Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test > On Mar 15, 2016, at 11:28 AM, Jordan Rose <[email protected]> wrote: > > 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 > Figuring out what debug *means* is an important first step. To "my people", it's the Xcode Build Configuration > Debug scheme setting. For language purposes, the only definition I can come up with at the moment is that debug is what happens when asserts can fire and are not disabled by compile-time optimizations. Is there a better definition? -- E _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
