[swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test
David Owens II
david at owensd.io
Thu Mar 17 13:45:42 CDT 2016
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: swift-evolution-bounces at swift.org [mailto:swift-evolution-bounces at swift.org] On Behalf Of Erica Sadun via swift-evolution
Sent: Tuesday, March 15, 2016 11:20 AM
To: Jordan Rose <jordan_rose at apple.com>; Dmitri Gribenko <gribozavr at gmail.com>; Joe Groff <jgroff at apple.com>
Cc: swift-evolution <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test
> On Mar 15, 2016, at 11:28 AM, Jordan Rose <jordan_rose at apple.com> 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
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list