Conditional Compilation in MonkeyC

I'm curious as to whether anyone else has hacked together a conditional compilation setup for MonkeyC.

It seems like something that would be nice to have built-in to MonkeyC since there's such a priority on small, efficient code; rather than have debug code, etc wrapped in feature flags, it's preferable to have it excised entirely.

I've written a Python script that hunts for the following tags // [strip:begin <tag>] and // [strip:end <tag>] and conditionally comments/uncomments code between those markers.

This allows me to quickly add remove logging/test fixtures in my test and release builds.

Anyone else doing something similar? Would there be any interest in me publishing this code? Or is this a bad idea for some reason?

Curious what folks thoughts are here...

Top Replies

travis.vitek over 8 years ago +1

Build exclusions are similar, but you can't completely compile stuff out. It does seem to work okay to allow you to write code that is used for one group of devices where an alternative exists for other…
FlowState over 6 years ago +1

ekutter great point. I think I understand why the system of excludes was chosen. It lends itself naturally to including everything by default.

However, this system breaks down when you only want to include…
FlowState over 3 years ago in reply to Ciantic +1

Ciantic said:
Isn't there a conditional compiliation even now, all 6 years later?

Here's the half-baked, basic solution that I use for some of my apps. It isn't updated for VS Code tho.

EDIT…

All Replies

markw65 over 2 years ago in reply to FlowState

FlowState said:
I don't think it'll work for your use case since it operates before exclusions are processed by the compiler.

No, it *applies* the exclusions, and generates optimized source after applying them. And yes, that means it can end up generating several copies of your source code when you want to export it; worst case, one per device, but it tries to be smart about which devices can share source.

And this is pretty much exactly what it can help with...

markw65 over 2 years ago in reply to Ciantic

Ciantic said:
Annoyingly close! It still leaves that variable allocation there

So I saw you reported this as an issue, but as I said there, I can't repro your exact problem.

When I run your code through the optimizer, I'm not left with a "message" variable if I pass a literal string to log. If I pass a more complex expression, then yes, it assigns that expression to message.

Version 2.0.26 (just released) has an unused variable cleanup pass that will fix this and many similar issues (whether or not they arose from inlining).

FlowState over 2 years ago in reply to markw65

markw65 said:
No, it *applies* the exclusions, and generates optimized source after applying them. And yes, that means it can end up generating several copies of your source code when you want to export it; worst case, one per device, but it tries to be smart about which devices can share source.

And this is pretty much exactly what it can help with...

Sorry my bad! That's pretty awesome.

jim_m_58 over 2 years ago in reply to FlowState

So when you build an iq file it could be using different source based on the device? If that's the case, it would really be a mess figuring out which source is used when looking at ERA.

flocsy🤠 over 2 years ago in reply to jim_m_58

I kind of had the same problem, even though I only got 3 different source directories. But actually it's not that bad, you have the generated release.jungle and from there you can see the source directory being used for each device

jim_m_58 over 2 years ago in reply to flocsy🤠

But if you just use jungles for different source for different devices, it's clear. Here how do you tell what source is used for a specific device if it's outputting multiple source files to the same place? (overwriting the last one?)

markw65 over 2 years ago in reply to jim_m_58

jim_m_58 said:
But if you just use jungles for different source for different devices

Thats exactly what it does. It generates a single jungle file that references the correct source files for each device. If you really want to know which files a device references, it's easy to find out. But the whole point is that it doesn't (shouldn't) change the behavior. So the only code you need to look at is the original...

jim_m_58 over 2 years ago in reply to markw65

Will things like line numbers change from the original source as you remove/add something or pretty print the code? If not what is being changed in the code you output?

FlowState over 2 years ago in reply to markw65

How would you personally handle reproducible builds with this system?

For example, suppose that today you tag a version of an app that you built with your prettier and released to the store, and 3 months later, you need to build that exact version (with identical generated source and output). Presumably the prettier extension would've been updated in the meantime, and the generated source would not be identical to what it used to be.

Would you source control the generated source and skip the prettier process? Or would you rollback to the specific version of the prettier extension that you used to build the app at release time (same idea as using the same version of the SDK that you built with)?

jim_m_58 over 2 years ago in reply to FlowState

I would just use the standard tools as I know they work and I can get to the exact source for every device with no thought!

Tools do not make a good programmer. Experience does!