I see no problem with having a bunch of @compileLogs here and there even after the testing is done. One annoying thing I currently have to deal with, is I have to look at the comptime logs and runtime logs. To do that, have to look at the comptime logs, comment all them out, and build it again to see the runtime logs.
I’m assuming there is a good reason why it’s designed this way, and if there is, please enlighten me.
It’s also possible to just have some global compile_log: bool somewhere and guard the logs you want to keep with that. So something like this:
// In something like 'config.zig'
const compile_log: = true;
// Then somewhere else
if(@import("config.zig").compile_log) {
@compileLog("foo");
}
The reason it is the way that it is is so that when you build a zig project you won’t get your logs spammed with a bunch of warnings/info since that gives a pretty bad impression, at least it would to me.
It’s meant for comptime print-debugging, which is why it adds a compilation error to remind you to remove those statements. As @pzittlau already pointed out, you can guard them with a flag placed in some config file.
Even cooler, you could add a built option, so you can pass just -Dctlog to the build command to enable the compile time logs, for example. No need to edit any file at all!
you’re right, having a lot of compile time logs can get noisy. but having to comment and uncomment a lot of lines every iteration was getting tedious and for some reason i thought this if (false) @compileLog("") will also give an error.
as the other two have suggested, i’ll put them behind a config flag