Interpreter: compile in release mode by default

[beta-ziliani]

When make interpreter=1 it makes sense to have implicitly also release=1, unless stated otherwise make interpreter=1 release=.

Follow up from #12609 (comment).

[beta-ziliani]

Pros: it saves us from "it's slow!". Cons: it's inconsistent from building the compiler itself.

[asterite]

I use that all the time and don't want it by default in release mode.

I think a warning message suggesting to also add release=1 might be good enough

[beta-ziliani]

Be that with or without the interpreter, in fact. WDYT?

[Fryguy]

I use that all the time and don't want it by default in release mode.

@asterite I realize you are the primary developer on the interpreter, but does this statement only apply to you, or would you expect all users to want it not in release mode?

[asterite]

Let's say it only applies to me and I want to compile in non-release mode. How do I do it?

[straight-shoota]

While working on the compiler (be that the interpreter or any other part of it) developers usually build in non-release mode for quick results. That's the most common use case and the one that should be most convenient. Just make (or make interpreter=1).

Release mode is typically only relevant for release builds. That's actually pretty similar for the compiler as it is for any other program.
And that usually doesn't happen very often. And if it does, it's often automated with build scripts. Adding release=1 to the make command for this use case is easily done. It must be clearly communicated to package maintainers (who are typically aware of this AFAIK) - and everyone who builds compiler releases.
I suppose a relevant group of those are users who want to try the interpreter and therefore build a release build of the compiler. They might not have much experience with building the compiler and don't have a regular build infrastructure in place.
They just checkout the compiler source and follow the instructions for building the interpreter. These instructions should mention to add release=1 (and prepare to wait for a while... so maybe also add progress=1?).

But I think the makefile is fine.

[Fryguy]

@beta-ziliani Said in the OP it would be make interpreter=1 release=, so I assumed that worked.

[Fryguy]

Maybe I'm misinterpreting the OP statement here and previous issue, but was the user using an official release build crystal or their own compiled crystal and did they build with release mode? I assumed they were using a compiler compiled in release mode and the interpreter wasn't in release mode, which doesn't make sense to me.

I would expect if you are using the official release or compiling the compiler yourself with release=1, then crystal and the interpreter would be in release mode. If you are compiling the compiler not in release mode, then I would expect neither crystal nor the interpreter in release mode.

Apologies if I misinterpreted.

EDIT: I just read @straight-shoota's response and what he stated is what I would expect.

[asterite]

I'm only wondering if shipping the interpreter, even if buggy, wouldn't be more helpful than thinking about this issue. People wouldn't have to build it, and it would already be compiled in release mode.

[asterite]

I would expect if you are using the official release or compiling the compiler yourself with release=1, then crystal and the interpreter would be in release mode

I think it's not clear for users that if you compile the compiler in non-release mode, it affects the interpreter performance. After all the compiler compiles, and the interpreter interprets, so if the compiler is slow it shouldn't affect the interpreter. But of course that's not true.

[beta-ziliani]

I'm only wondering if shipping the interpreter, even if buggy, wouldn't be more helpful than thinking about this issue. People wouldn't have to build it, and it would already be compiled in release mode.

I'll repeat myself: the issue is not the state of the interpreter, but the release process that needs to be adapted significantly. We do want to ship it.