It's great to simplify these things, but what would you do about the tracing? Do you think we could get rid of the if-statements if one had a properly lazy approach, like this, or do we still need the conditional crap? I think our current framework also does not create the docs, but it still invokes the printf pseudo-printer, even when the tracing subsystem is disabled.

It's great to simplify these things, but what would you do about the tracing?

This is particularly confusing, even from purely build system point of view. I thought it would be good to use dune's promotion such that these generated files show up in the src directory instead of having to inspect them inside _build/default/src if necessary. Removing make gen seems to make it possible at first sight (removes a cyclic dependency), but it doesn't actually work: these trace_on/off scripts change the ones in src directly, but promotion always regenerates them inside _build and copies them back (by overwriting).

One idea I had would be to use dune profiles such that one has to create (but not commit) a dune-workspace file to change the profile. And based on the profile the boolean could be switched via some dune rules hopefully. But it's not also very clear if this is an intended use case of dune profiles or not.

Do you think we could get rid of the if-statements if one had a properly lazy approach, like this, or do we still need the conditional crap?

I wonder how that approach actually compares to ours, it's not so obvious. That one still always calls some external library function, not sure how much that gets optimized. Ours on the other hand has an explicit if using a compile-time constant boolean, which I guess is supposed to be optimizable. I haven't tried to ever check though whether it actually is.

I think our current framework also does not create the docs, but it still invokes the printf pseudo-printer, even when the tracing subsystem is disabled.

That's probably true, but it might not have notable overhead since by ignoring everything it doesn't really do much other than iterating through the format string once. Generalizing to Format might be more optimal due to all the GADT optimizations with format strings, but that's a whole project on its own anyway (#213).

Another thought I've had at some point is maybe using a ppx rewriter to have a special extension point for our tracing, which would avoid having to write the ifs. But this makes the code even less readable and reusable because it depends on our own ppx rewriters, so I'm not sure I'd actually want to ever do that.

I went all in now and completely replaced these generation things with dune rules, including the entirety of set_version.sh. I wonder if we should be this extreme.

We should update the docs as well. I think they explicitly refer to these trace scripts.

Also, I get build errors when trying this. Interesting that the CI has no problems. Would be nice to have something like make upgrade that basically works like rm -rf _opam; make setup; make dev. Typically the opam install --deps-only . and upgrading cil would work. Not sure if that's quite the same as make deps?

[So in this case it would also have to remove an existing pin... maybe not so easy for a script to cover all such things.]

I think they explicitly refer to these trace scripts.

The scripts are still there and still work though, right? Or did I misunderstand?

Yes. They work, but it's not ideal to recommend stuff that immediately print out "hey, we're deprecated" :)

The scripts are still there and still work though, right? Or did I misunderstand?

Yeah, I decided to adapt them for now, so the previous workflow for switching to trace mode still works. Although you could just create the dune-workspace file yourself and simply go edit that to change, no need to invoke the scripts.