IntelliJ Does not respect omit-trace-statements=true

[RossD20Studios]

Problem Description

Describe your problem in detail. Include the following information:

AIR SDK 33.1.1.620 Compiling on Mac OS 10.14.6 Mojave

Steps to Reproduce

1. Set the -omit-trace-statements=true in the Additional compiler options OR by using a compiler configuration file with trace statements omitted.
2. Run the build the build in either run mode or debug mode, and observe trace statements
3. Package a release build and profile with Adobe Scout. Observe trace statements.

Compiler option set

Even with a release build, Scout shows the trace statements are still there.

Known Workarounds

Compile using Adobe Animate with the Omit trace statements option checked. I confirm that running the build in debug mode and profiling a release build in Adobe Scout using Adobe Animate does not export the trace statements.

[RossD20Studios]

As an additional work-around solution, I have also considered using Conditional Compiler definitions. For example: CONFIG::trace. Then, in the code, I could wrap all existing trace statements as follows:

CONFIG::trace {trace("returnAssetToPool: " + asset.name);} In this way, trace statements can be included/excluded from compilation for release builds. I have confirmed this solution works in IntelliJ, though I would still hope the omit-trace-statements flag can still be addressed.

[ajwfrost]

Hi @RossD20Studios

The odd thing here is that looking at the source code for the new compiler, I don't actually see what omit-trace-statements does... i.e. there doesn't seem to be anything using the internal flag that's set when you change this value! So I may be missing something, but there might be another factor at work here.

Animate of course may well be jumping into the compiler or supplying its own front end for this. We may need to have a bit of a test with a custom build of the compiler, to see what Animate is actually doing. I can't see anything that actually goes through the code to strip out the trace commands though..

Interestingly though - the description for this compiler option when you look at FlashDevelop is:

Remove trace() calls from your code when compiling in release (not debug) mode.

But ... having just had a bit of a play ... the new compiler (from AIR) does not appear to support this flag at all. When I use the command-line, it's not giving any difference regardless of whether it's a debug or release build. When I switch to an SDK using the Flex compiler, then the flag is used, and can be used to include traces in a release build via -omit-trace-statements=false (by default, traces are removed).

So this just appears to be something that had never been implemented for the new AIR compiler....

I'm also curious when you say you were using Animate, in debug mode, and could remove traces. I guess the functionality may be within Animate itself (or via the Flex compiler) but I can't really see how this would work otherwise!

Anyway ... this would be an interesting exercise to see if we can properly support this within the newer compiler....

[RossD20Studios]

Very interesting findings @ajwfrost ! It is a concern of mine how the compiler performs differently in Animate - especially when it can have far reaching consequences as this example demonstrates. By not removing trace statements (as I thought the application was) it can have impact on application performance for different users.

On a side note - another quirk I've noticed is that IntelliJ can't force close the AIR compiler, but Animate can. This can be quite disruptive to workflow when you encounter bugs. In Animate, I can just tick the "X" to shut the whole compiler down. In IntelliJ, I'll try the same thing (it works maybe 50% of the time) - but if it doesn't work, then the compiler gets stuck and I have to go through a 30 second process of "Force Quitting" the application with the MacOS.

Anyway, I really appreciate your team looking into fixing this for the newer compiler. The workflow in IntelliJ is so much better than Animate: the ability to build multiple platforms at the same time, and the debugger is superior (ability to see all the variable values directly in the source code vs. having to drill down into tiny little components to find them) - so it would be fantastic for the compiler to support this natively.

[ajwfrost]

@RossD20Studios here's a question for you .... having looked at this a bit more, omit-trace-statements is being set internally to true in the default configuration of the compilers. Even in debug builds. So, if we do hook up the functionality so that this option actually does omit the traces, it means traces would disappear from debug builds unless you had explicitly set them with -omit-trace-statements=false in your build.

I'm not 100% happy with this idea, as it would change the behaviour for the vast majority of people. My feeling is that we should go for logic along the lines of:

• if there is a config/command-line option for omit-trace-statements, then we use that
• otherwise, if you have optimize set to true, or debug set to false, then we also omit the traces
• otherwise (so if you're not specifying, not optimising, and doing a debug build) we will output the traces

Would be interested in your thoughts!

[RossD20Studios]

@ajwfrost These are excellent points. I've never understood the use-case where you would export a release build and want to leave trace statements on. Trace statements can only be viewed in the debugger or Adobe Scout, and I can't imagine how they would be useful in Adobe Scout.

Personally, I've always found it frustrating to explicitly have to turn off trace statements when creating a release build. Most of the time that I am developing, I am running the debugger, so naturally, I want trace statements on. Then, when I go to build a release, I have to remember to explicitly turn trace statements off. More often than not, I forget to turn them off, and then players complain about lagging in the game.

So, yes, please do as you propose! This is a much better workflow.

What does the optimize flag do? I've never set this flag. Is this flag automatically set when creating a release build or does it have to be set explicitly?

If this has anything to do with further improving code performance, then I think the default here should also be to enable optimize whenever debug mode is false (unless explicitly set otherwise).

[ajwfrost]

What does the optimize flag do?

That's a good question :-) I just had to look through the compiler code to find out. Basically it tries to optimise the ActionScript byte code in the 'link' stage, by removing things like unnecessary coercions and dead code branches, label texts, etc. So the goal appears to be speeding up execution a little.

Default value is true - so it's generally always being used... and interestingly this is also set in the default config file:

        <!-- Enable post-link SWF optimization. -->
        <optimize>true</optimize>

and this default will be the case for both release and debug builds.

So actually, this makes me think that we should just go with:

• if there is a config/command-line option for omit-trace-statements, then we use that
• otherwise, if you have debug set to false, then we also omit the traces
• otherwise (so if you're not requesting they're omitted, and are doing a debug build) we will output the traces

[RossD20Studios]

Perfect, that sounds great @ajwfrost ! I can't wait to see this in a future release. It's so much easier to manage my numerous build configurations in IntelliJ (and be able to output them all at once) vs. having to maintain/individually export from a dozen Animate files ;)