Descriptive Problem Summary:
After updating to the new beta, DEBUG no longer works.
Numbered Steps to Reproduce Problem:
1) Download and install beta build 499.1183
2) define DEBUG
3) Rant to Vrocaan for awhile
4) Wait until he doesn't show any sympathy
5) Make a bug report
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
DEBUG to work
Actual Results:
Image!
Does the problem occur:
Every time? Or how often? yar
In other games? DM problem
In other user accounts? yar
On other computers? yar
When does the problem NOT occur?
Neva
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Last build I had that I -think- it worked in was 499.1181
Workarounds:
Revert to a previous build
ID:1261056
 May 10 2013, 3:20 pm (Edited on May 10 2013, 3:35 pm)
|
|||||||||||||
Resolved
| |||||||||||||
|
May 10 2013, 3:46 pm
|
|
Tom
 |
Hmm, I did make some changes in how the DEBUG system works for clean-compiles, so I probably broke it. Are you just #defining it in code or through the properties?
|
Just as it's shown in the image. I define it once and that's pretty much about it.
It just doesn't work in general. I ran into an error in-game, but wasn't given any specifics as to what file/line the issue originated from. | |
Tom resolved issue
| |
Ok, so it turns out this was intentional, but I'm willing to change it back. Basically what I did here was make it so that the "Generate debugging information" as set through the Code Preferences is always respected (overriding any #define DEBUG statements in the code). The reason for this is that I noticed some external libraries have #define DEBUG embedded, which enables it for the entire project.
That said, the main change here is to make it so that the zip generated through "Package Files" is always in release mode, ignoring any #define DEBUG calls in the code (or if the project is set as a DEBUG project in the build preferences). Since you probably don't care about debugging info outside of distribution, maybe the aforementioned change doesn't matter. Let me know what you guys think and I can do it either way. I didn't actually realize people were mainly setting #define DEBUG in code (but since it's in the ref, I guess we should respect it?) | |
I noticed a change and found it in the code preferences and set it, albeit I usually set #define DEBUG in the code itself. I'm fine with the change.
| |
Ah, I see. Well you could just continue with the way you were doing things. Although it's not major manual labor, I'd be lying if I said removing/adding #define DEBUG wasn't annoying when it comes to packaging files.
I'd prefer having to set it via code preferences as opposed to having to go back an manually removing #define DEBUG from whatever libraries I use, so the change is alright with me. | |
Well, the packaging files things works correctly now whatever we decide on this (that is, it always removes the DEBUG flag). The only question is whether we want to respect #define DEBUG in code or always use the project prefs. It's trivial either way (I tentatively have reverted it to respect the code).
To be clear, the reason for the change was that I found that some people had included #define DEBUG in their distributed .dme libraries which made it impossible to unset outside of editing those libs. (I'm leaning towards moving back to respect the project prefs, since it seems straightforward and gives the user full control without having to worry about any outside code.) | |
When this hits general release, I guess in the Linux/*BSD compile scenario, you've got no choice but to go on the #define value?
I know I and some of the SS13 projects build projects in an automated manner off of a continuous integration server, and in my case at least, this is a Linux box. | |
The Linux compiler still respects DEBUG. This is just something from the IDE. We can easily go either way here.
| |
Awesome, cheers.
| |
I prefer to be able to put #define DEBUG in the code somewhere and have it enable debug mode. I think people who make distributions should be held responsible to do this properly and not be idiots.
| |
The problem somewhat is that these distributions are old, sometimes popular, and the authors / hub editors are no longer available. In principle though, I completely agree with you.
| |
Why not just have #define DEBUG stored within the .dme file, and only search for it there for the project you are compiling, and have the checkbox in DM go off of that value?
| |
Flame Sage wrote:
Why not just have #define DEBUG stored within the .dme file, and only search for it there for the project you are compiling, and have the checkbox in DM go off of that value? That's the way it used to be. I think unchecking it in preferences should delete it from the code files. But that's probably too intrusive. | |
FIREking wrote:
Flame Sage wrote: I don't see why it would be intrusive. I would think the IDE should integrate into the project you have open. I see nothing wrong with keeping those two in sync with each other. | |
Heh, I feel like we're making a bigger deal of this than it is. It's really no big deal and if the old behavior was better, we can keep it. This new behavior actually doesn't change anything in the file-- it just tells the compiler to ignore the DEBUG flag if you don't have the "debug info" preference selected. The primary reason was to ensure that this flag is always off when packaging files for distribution, and it will now do that regardless of how we handle the default compile behavior.
To reiterate, the argument for the new behavior is mainly to give you, the developer, full control over the DEBUG behavior of your project without having to go through all included libraries. The alternate behavior will force your project into DEBUG if even a single library has that #defined somewhere. Of course, this may not be a big deal. | |
FlameSage, the new proposed behavior will do exactly as you want; the old way did not because an external DEBUG would override your setting in the .dme. My opinion is the new behavior is better but I don't care that much so if it's a big deal, I can go back.
| |
I think its quicker to just type it in there, and to maybe have it enabled / disabled based on values... like
#ifdef MAPEDITOR So whatever makes that possible, lets do it! | |
The new behaviour sounds pretty much ideal. Your project's DME is pretty much the config/control point, and you'd want to ignore it in libraries.
| |