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 2 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:
How would you personally handle reproducible builds with this system?

What I've done so far is create an export job called "release" in tasks.json which sets outputPath to ${workspaceDir}/releases. When I run that task it creates a .iq file, and puts the generated code in the "releases" directory, which I can then commit and tag (I would have tagged the original source anyway).

But that's more so that I can go back and check it, just in case I see issues. There's currently no support in the extension to actually rebuild those sources, but It would be pretty easy to rebuild it by running "sdk/bin/monkeyc -f releases/release.jungle" from the command line.

That said, I can't really think of a good reason for doing so (but I agree that build reproducibility in general is important).

One thing I've noticed is that .iq files don't seem to be reproducible anyway; if you build the same project twice, the .iqs will be different (probably just a time stamp, but still). Also, if you build the same project from two different locations (ie two checkouts, of the same code, at different paths), the individual .prg files can be different - and *will* be different for debug builds. So reproducibility is already an uphill battle...

FlowState over 2 years ago in reply to jim_m_58

jim_m_58 said:
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!

Yeah, I was just asking markw65 how he would envision his tool being used in the context of a best-practices development process such as reproducible builds. Neither endorsing nor criticizing his tool.

jim_m_58 said:
Tools do not make a good programmer. Experience does!

Is that why people resisted the move from Eclipse to VS Code? Or why people who want to build from the command line are criticized?

"Tools don't matter"

"You should only use the tools that I am personally comfortable with"

FlowState over 2 years ago in reply to markw65

markw65 said:
One thing I've noticed is that .iq files don't seem to be reproducible anyway; if you build the same project twice, the .iqs will be different (probably just a time stamp, but still). Also, if you build the same project from two different locations (ie two checkouts, of the same code, at different paths), the individual .prg files can be different - and *will* be different for debug builds. So reproducibility is already an uphill battle...

Yeah that's what I was thinking, but at least you want the generated source to be reproducible, so that (historical) stack traces line up.

Like say you're looking at a stack trace for an older version, but you don't have that generated source around anymore. I guess that scenario is pretty unlikely given how ERA works, but ofc it's possible that you saved the stack trace locally for your own purposes. (Like you're aware of a bug in a past version, but you didn't fix *all* the bugs in the latest version. I know some people here suggested fixing ALL your bugs in every release, but given that Garmin never does that with their watches, seems like a high bar for hobbyist coders.)

FlowState over 2 years ago in reply to FlowState

I will also point out that good tools improve developer productivity, whether it's an IDE released by a huge company like JetBrains or Microsoft, or a shell script written by a sole dev for their own use.

The whole point is to avoid wasting time doing stuff which can be automated. This saves time, and in some cases, avoids costly mistakes. You also want to reduce unnecessary cognitive load on devs so they can spend their time and energy solving hard problems.

The fact software dev tooling and practices are constantly evolving points to the fact that we haven't reached "perfection" yet, where no improvement is possible.

In my day job I've worked with custom languages that have almost no tooling and standard languages which have first-class support built into every modern IDE. I can work either way, but I know which way I prefer.

flocsy🤠 over 2 years ago in reply to FlowState

Either you source control the original src (which you do anyway) + you also "source control" the version of the prettier-monkeyc plugin.
Or you source code the output in bin/optimized.
Or because anyway the only version you'll ever get an ERA report from is the current you don't need to source control it, it's enough to save bin/optimized until the next release...

flocsy🤠 over 2 years ago in reply to jim_m_58

But good programmers do know what tools to use :)
Campaining against a tool that is successfully used by some people is totally unnecessary, I would even say a bit stupid, even more considering that from your comments it's clear you never tried it.

_psx_ over 2 years ago

I don't use this tool because I don't need it (yet)n and use eclipse...

Everyone choose his tools especially when original is not good - because optymalizator should be built in sdk!!!

I can't understand how is impossible to offer 3rd party developer 65kb/92/... memory and no optymalizator.

So great regard for markw65 for his job, job should made by Garmin.