Add version commands for more languages/executables #2541
Conversation
|
@meisterT should this just replace what we do in the default data? If you wipe your database we always run the migrations and we always run the defaultdata fixture so one of them is redundant. I think the migration is better as it also helps in case people upgrade. |
|
I would keep both. The migration is clearly necessary now when you upgrade. The defaultdata fixture is way nicer when you add a completely new language (we wouldn't add a migration for that). |
I think when we add a new language and you upgrade you would indeed not get the new language. |
|
And that is fine. Adding a language is a conscious decision anyway and requires changes to the chroot typically. |
vmcj
force-pushed
the
language_chroot_setup
branch
2 times, most recently
from
2388bbf
to
81295dd
Compare
vmcj
force-pushed
the
language_chroot_setup
branch
from
81295dd
to
e14546f
Compare
vmcj
force-pushed
the
language_chroot_setup
branch
from
4f79a5c
to
86a89c8
Compare
vmcj
force-pushed
the
language_chroot_setup
branch
from
06015e2
to
0a94981
Compare
vmcj
force-pushed
the
language_chroot_setup
branch
from
f3dfe09
to
497587d
Compare
sql/files/defaultdata/hs/run
Outdated
| @@ -10,6 +10,9 @@ MAINSOURCE="$1" | |||
| # Set non-existing HOME variable to make GHC program happy, see: | |||
| # https://ghc.haskell.org/trac/ghc/ticket/11678 | |||
| export HOME=/does/not/exist | |||
| # Allow temporary files during compilation, this directory is not | |||
| # available during the submission run. | |||
| export TMPDIR=`pwd` | |||
There was a problem hiding this comment.
pwd is the command to get the current work directory. Why do you prefer $PWD over pwd?
There was a problem hiding this comment.
pwd spawns a process, $PWD just reads an environment variable
I'll wait for @eldering his review and will squash afterwards. |
DOMjudge ships with default languages but no documentation on how to install those. This commit documents how to get a working setup in the chroot to get the example problems to run. In the past we had the idea to enable all languages in the integration test. If we would do that we could detect the required package changes also and keep this up to date. For the interpreted languages we use mostly use the same binary as runner & compiler. Some of the versions were already added before and are only documented on how to install those now. The migration is added for people to get the version commands to make it easier to use additional languages and still make it easy to publish the used versions, useful for online mirrors etc. The version for `dash`/`sh` is difficult as there is no simple `--version` and getting the value with `dpkg -s` does not work inside our chroot during runtime as not all locations are mounted. For more information see: https://stackoverflow.com/questions/36660724/how-to-tell-the-version-number-of-dash and https://unix.stackexchange.com/questions/416760/how-to-find-out-the-version-number-of-dash-without-resorting-to-package-manage. The other alternative would be `file` as that gives more information than `md5sum` but its also not available in the chroot. The installation for swift could be easier if we allow tarballs to be unpacked in the future. At the moment people would either need to change `dj_make_chroot` or do it afterwards with `dj_run_chroot`. Javascript is interpreted so we copy the behaviour of python. While testing I found that we can only have run-error but there is a `--check` which we could use to verify that there is a sort of compilation step.
Contents based on the values in the DefaultData/LanguageFixture.
vmcj
force-pushed
the
language_chroot_setup
branch
from
58ddce2
to
d074fff
Compare
This tries to be non-destructive for upgrades but would remove the command if people have picked the same command and they choose to run the
downmigration, in that specific edgecase I assume people know what/(and why) they are doing this.I've not done all the languages yet as I would like some feedback first.it now has all known languages for my installation.