On Thursday 18 November 2010 13:29:15 Jens Mueller wrote: > Jonathan M Davis wrote: > > On Thursday 18 November 2010 12:08:19 Jens Mueller wrote: > > > I like it. > > > Thanks. > > > What I'd even like better (because contracts are release specific): > > > release { > > > > > > const currentWidth = width; > > > const currentHeight = height; > > > scope (exit) { > > > > > > assert(currentWidth == width); > > > assert(currentHeight == height); > > > > > > } > > > > > > } > > > But that does not work. Why do we have special syntax for debug but not > > > for release. Both seem to me very similar. In the end I tend to think > > > release/debug as a shorthand for version(release/debug). But that's > > > not quite right. Somehow it's allowed to write version(unittest) {} > > > equivalently for unittest {}. But for debug/release there is no such > > > thing. Why this asymmetry? > > > > One thing that you need to realize is that the -release and -debug flags > > are _completely_ unrelated. You can use none, or one, or even both. > > > > -release disables assertions (other than assert(0)) - including removing > > all pre-conditions, post-condition, and invariants - and removes array > > bounds checking for @system and @trusted functions. > > > > -debug enables all debug blocks. > > > > So, you can have > > > > * Neither flag: All assertions, contracts, and array bounds checking are > > enabled, and debug blocks are not compiled in. > > > > * -release only: All assertions, contracts, and array bounds checking for > > @system and @trusted functions are removed. debug blocks are not compiled > > in. > > > > * -debug only: All assertions, contracts, and array bounds checking are > > enabled, and debug blocks are compiled in. > > > > * Both flags: All assertions, contracts, and array bounds checking in > > @system and @trusted functions are removed. debug blocks are compiled > > in. > > I think unittest should be added to this list. Because it can cause more > confusion. > > > So, the flags in question are quite confusing really, and talking about > > debug mode doesn't actually make sense when you think about it. You have > > release mode and non-release mode. And you either have debug blocks > > enabled or you don't. And on top of that, you have whether debug symbols > > are enabled or not (even worse, there are two different flags for > > enabling debug symobls: -g and -gc). So, the flags as they are make the > > whole release vs debug build thing really confusing, and they're > > probably not terms that really should be used unless you're talking > > about your specific build process and the specific set of flags that you > > use for building for release builds and the specific set of flags that > > you use for debug builds. But talking about release and debug builds is > > so ingrained in people, that they keep using the terms anyway, and most > > people probably don't quite understand the imprecision of the terms with > > regards to dmd. > > I totally agree with you and I think one should fix dmd's help message. > I would love to see > -release same as -nocontracts -noasserts -noboundscheck > -debugging same as -debug -unittest -contracts -asserts -boundscheck > -testing same as -unittest -contracts, -asserts, -boundscheck > > These switches basically configure your software (which code to > compile). And above you find the typical configurations for release, > testing and debugging. One could leave out the defaults. > > Having orthogonal command line switches: > -(no)boundscheck compile in array bound checks > -(no)contracts compile in contracts > -(no)debug compile in debug > -(no)unittest compile in unittest > -(no)assert -noassert causes assert(<compile-time constant>) > to be translated to hlt > with some sensible default (but only disabling the default might be > implemented) e.g. > -nounittest > This we have already. Because we -unittest. > -nodebug > This we have as well via -debug. > -boundscheck > This too (-noboundscheck). > -contracts > Missing: -nocontracts > -assert > Missing: -noasserts > > But I think this can lead to something like -unittest -noassert which is > rather strange. Don't know. Would still go for it. > > And now as you say one can specify -g for debug symbols or -O for > optimization. > In summary there are two things to consider: > 1. What code will be included? (debug, unittest, contracts, assertions, > boundschecking, and version=xxx) > 2. How will the code be generated? (with debug symbols -g, -gc; > optimized -0) > > Typical release code is built via -release -O I'll guess. It's true > -release does not do a release build as one expects. Same for > -debugging. Because -g is missing. Better names would help here. But > it's difficult to change that now, isn't it? That's why better dmd > --help output should be sufficient.
I don't think that they're all that hard to understand and use as it is, but I do think that there is often a fair bit of confusion about them at first, and there is _definitely_ confusion about it in discussions because of terms like "debug build" which are arguably next to meaningless but get used all the time anyway. - Jonathan M Davis