simplify extccomp.nim json logic via jsonutils; fix #18084

[timotheecour]

• fix -d:nimBetterRun (or nim r) should recompile if set of config files change #18084
• simplify extccomp.nim json logic via jsonutils
  the resulting code is much simpler, concise and maintainable (removes 100 LOC, and more after we'll remove the bootstrap workaround)

[Araq]

No. If you want to improve this, give us a "jsonbuilder" module first. One that doesn't repeat json's mistakes.

[timotheecour]

@Araq are you referring to timotheecour#745 (serialize/deserialize directly from string instead of from intermediate JsonNode) or to something else? If so, yes I agree timotheecour#745 is needed down the line for performance in similar cases but it would be a 1 liner change on top of this PR once that feature lands. If you're worried about performance I can make a benchmark but I don't see a reason why this PR would create any meaningful overhead.

the name jsonbuilder sounds like it'd be instead similar to the json.%* operator (%* {"age":35, "pi":3.1415}), but that's worse than what I'm doing as there's no spec/type-safety and serialization/deserialization would need more synchronization, unlike this PR with BuildCache (which is analog to a protobuf proto)

this PR is a big code simplification as evidenced by the diff

[Araq]

serialize/deserialize directly from string instead of from intermediate JsonNode)

Yes, that's my point.

If so, yes I agree timotheecour#745 is needed down the line for performance in similar cases but it would be a 1 liner change on top of this PR once that feature lands.

I fail to see how.

the name jsonbuilder sounds like it'd be instead similar to the json.%* operator (%* {"age":35, "pi":3.1415}), but that's worse than what I'm doing as there's no spec/type-safety and serialization/deserialization would need more synchronization

I don't understand but jsonbuilder's API is not outlined anywhere so it's hard to communicate.

[timotheecour]

it would be a 1 liner change on top of this PR once that feature lands.

I fail to see how.

once timotheecour#745 lands, the code in this PR can be changed as follows:

conf.jsonBuildFile.string.writeFile(bcache.toJson.pretty)
...
bcache.fromJson(jsonFile.string.parseFile)

=>

conf.jsonBuildFile.string.writeFile(bcache.toJsonStr(pretty = true))
...
bcache.fromJsonStr(jsonFile.string.readFile) # or directly from a stream to avoid `readFile`

toJsonStr is defined (briefly) in timotheecour#745

in the meantime, there should be no performance penalty resulting from this PR even in absence of toJsonStr, fromJsonStr

[timotheecour]

there should be no performance penalty resulting from this PR

and indeed, here are timing results:
if i instrument (and compile nim with -d:release as is usual) writeJsonBuildInstructions with let t = cpuTime() at beginning and echo cpuTime() - t at end, here are results (best of 3 runs):

before PR

nim c compiler/nim 0.0006
nim c -f compiler/nim 0.013 # more expensive because it calls getCompileCFileCmd in this case

after PR

nim c compiler/nim 0.0006
nim c -f compiler/nim 0.011 # ditto

=> no performance drop as a result of this PR, not that there's anything surprising to that.