Compare scripts should be build using language defaults

[RagnarGrootKoerkamp]

Currently the judgedaemon has hardcoded compile commands for executables (output validators / interactors).

It would be nicer if this reused the configured language compile scripts from the DOMserver settings, i.e. the default build and run script for the language.

[meisterT]

I fully agree - are you willing to contribute this?

[RagnarGrootKoerkamp]

Yes I'll give this a try. I think these scripts are already fetched and used for compiling team submissions right, so it shouldn't be too much work

[RagnarGrootKoerkamp]

I think I should be able to reuse most of the existing compile function for team submissions.

The tricky point is mapping an executable to a compile script/id. It seems that currently no language detection is done on the judgedaemons, so they would need to fetch this information from the database first, right? (Of course we could still keep the switch over extensions, but that feels wrong.)

Then, we need the up date compile_config for all languages so we can know the most recent hash and fetch the executable.

Basically, it seems that we need to query the database each time before compiling an executable. Is that possible, and does it sounds like the right approach?

---

Also, here's a pedantic case: Suppose the executable for the xyz language only consist of a main.xyz file that should be automatically compiled to a run binary used to compile files in the xyz language. Now to do this, we need to fetch the compile script for the xyz language, but that first needs to be build, and so on.

(But this is easily avoided by disabling the language-detection for language-compile executables, and only doing it for compare scripts.)

[RagnarGrootKoerkamp]

Oh, or we could do language detection for executables early on and store it in the DB, and then send this language, together with compile config when the executable is fetched here