Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Make version blocks independent from the backend #404

shamanas opened this Issue · 8 comments

3 participants


We often hear talk about separating ooc from its C roots lately and make it possible to write backends that target other languages, so this is, I feel, another necessary step. I feel like rock should at all points know what flags are set and ignore resolving code in version blocks that do not match those.
One of the problems to implement this is OS detection in rock without ooc supporting version blocks though but that would be achievable with flags set at C compile time.


And yes, I know this would be a pain to bootstrap, but still ...


I was talking with @minirop and @araq, and we decided that a static if may do the trick.

static if (unix || apple) {
    // I'm UNIX or OS X/iOS!
} else if (windows) {
    // I'm Windows!
} else {
    // I'll be used by everything else, including non-C backends!

Even if it doesn't, I think static if or similar would be nice. The name version doesn't seem to fit as nicely, to me, and afaik we don't have else if/else with version blocks.


Since it's at compile-time, it can treat undefined things as "false" normally. This still needs things like an --ifdef flag if we want to not write all the code by default.

Also, this would allow such things as...

} else if (javascript) {
    // Ohai from the world of ooc-in-javascript!
} else if (jvm) {
    // Ohai from the world of ooc-on-JVM

...without near as much boilerplate. Do you love me yet? ;D

tl;dr: It doesn't fix the issue, but I think it'll be merely a thorn, as opposed to a nail.


/me puts his BDFL hat on.

@shamanas One of the great things about rock is that it produces C code that you can compile on all platforms. Which means we have to resolve all the ooc code for all platforms.

In practice it's really not such a big deal imho, and it's really really great at usage, one of the great qualities of ooc, I'm not ready to let that go.

As for version blocks, they're already independant: 'linux', 'osx' etc. are mapped to the relevant C symbols. For other backends, they can be mapped accordingly.


@nddrylliog apparently I was still half asleep or something when I wrote my comments, because I'm not sure how much it'd really help, BUT anyway... can version blocks do something like to what I mentioned above, and if not, what do you think of either: 1) making version blocks capable of doing that, or 2) migrating to something like the static if?

I personally think static if is nicer, but as long as version blocks can do something similar I don't particularly care. :P


@duckinator 1) There are 'else' for version blocks, I don't remember who implemented it but it's functional. 2) you're basically asking for a preprocessor: rock doesn't do that yet, and it shouldn't be added at that point. What I would recommend is to do it at AST level, as a plug-in once we complete the clean-up (ie probably post-1.0)


-- your beloved bdfl


This issue caught my eye because I'm implementing ooc on top of LLVM for scissors. I still think version blocks are good enough for now - and that JavaScript/JVM implementations are but a dream so far because of our strong ties to C or at least, native.

If I run into issues while doing the LLVM thing that are related to that, I'll re-post here, but in the meantime I suggest we close this issue.


(Btw, JS implementation exists thanks to emscripten: bt I get what you're saying)

@shamanas shamanas closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.