Find a way to import compile commands or compilation flags

[RagnarGrootKoerkamp]

I think someone else also brought this up last week. It would be nice if there was a way to automatically import compiler flags (or just the full compilation scripts, but compile and run command only as in languages.yaml would be preferable).

That way we can just re-import a contest/problemset instead of having to manually edit the file each time.

[meisterT]

I agree that this would be a nice feature, it would also allow us to display these in the team interface.

Is there a spec for languages.yaml that we can use?

[RagnarGrootKoerkamp]

I don't think it's officially spec'ed yet, but problemtools has the ground truth. The comments in the file explain the syntax.
https://github.com/Kattis/problemtools/blob/develop/problemtools/config/languages.yaml

BAPCtools also uses it.

[RagnarGrootKoerkamp]

One thing to keep in mind is that currently DOMjudge only has global language settings, so importing this for a contest would necessarily override the global settings, so there needs to be some extra warning/confirmation somewhere.

[nickygerritsen]

The API spec now has fields for compiler flags (and run stuff), which is probably the spec we want to go with.

[meisterT]

Can you please link to the (new?) section in the spec?

[nickygerritsen]

https://ccs-specs.icpc.io/master/contest_api#languages

see compiler and runner

[meisterT]

(link moved to https://ccs-specs.icpc.io/draft/contest_api#languages)

[meisterT]

This will be a lot easier when #1238 is implemented.

[meisterT]

I started implementing supporting compiler and runner version commands the first step and discussed the approach with @tuupke yesterday.

The idea is that you can define for each language a version command and an optional runner command. The judgehosts can collect the output of these commands and we can create an (optional) languages page for the teams that shows the enabled languages and their versions (later also the command lines).

There will be an easy way to mark one of these outputs as canonical and promote it from this table to the language table.

Upon registering / judgehost startup, for each enabled language, the judgehost runs the version commands and reports back the output. In the database we need a new table where we store the (most recent) output for each combination of language and judgehost.

When handing out judgetasks, the judgetasks get enriched with the version commands. Then, on compilation of a submission, you also run the version commands and report them back with the testcase result.

In strict mode, the server compares this output with the canonical output. Then it ignores the result (of this testcase and all other cases in the batch) and disables the judgehost (or judgehost/language combo).

In non-strict mode, this could at least be flagged on the submission itself (and perhaps as an internal error which is not disabling anything, but less easy to miss).