search

DOMjudge / domjudge

DOMjudge programming contest jury system
https://www.domjudge.org
GNU General Public License v2.0
734 stars 258 forks source link

Find a way to import compile commands or compilation flags #1241

Open RagnarGrootKoerkamp opened 3 years ago

RagnarGrootKoerkamp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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

meisterT commented 2 years ago

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

nickygerritsen commented 2 years ago

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

see compiler and runner

meisterT commented 2 years ago

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

meisterT commented 2 years ago

This will be a lot easier when https://github.com/DOMjudge/domjudge/issues/1238 is implemented.

meisterT commented 1 year ago

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).