You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the compiler and runner version are part of the language table, but they are directly related to the compiler executable associated to the language, not the language itself. Thus, they should also be stored there.
The text was updated successfully, but these errors were encountered:
A change in executable will not change the compiler/runner versions.
You need to change the chroot to change the versions instead. That's why the version table stores this info per langid and judgehostid. It then get's promoted to the language table when marked as canonical.
For more context, see #1241 (which I incidentally picked up a few days ago).
A change in executable will not change the compiler/runner versions.
You need to change the chroot to change the versions instead. That's why the version table stores this info per langid and judgehostid. It then get's promoted to the language table when marked as canonical.
Well, that's also true. But if I change the executable for language C++ from c++-with-gcc to c++-with-clang, then I will definitely get a different compiler version too. So I think that this is more directly related to executable than language. I do agree though that we should show it at the language level.
For that my plan is to follow the spec (see https://ccs-specs.icpc.io/draft/contest_api#languages) and add compiler and runner fields in the language table. Then these will be passed to and can be used by the executable scripts as variables.
Currently the compiler and runner version are part of the language table, but they are directly related to the compiler executable associated to the language, not the language itself. Thus, they should also be stored there.
The text was updated successfully, but these errors were encountered: