aboutsummaryrefslogtreecommitdiffstats
path: root/contrib/libs/libjpeg-turbo/jdatadst.c
diff options
context:
space:
mode:
authorspreis <spreis@yandex-team.com>2024-03-28 11:07:37 +0300
committerspreis <spreis@yandex-team.com>2024-03-28 11:17:45 +0300
commit2de742ce97267f0469cf0c9bd384488c91442bce (patch)
tree15daa45ea6fb7ecfd1e07759c7bbd6fba92075a6 /contrib/libs/libjpeg-turbo/jdatadst.c
parent48212452a70da88a5e4b814979dd82f22379801f (diff)
downloadydb-2de742ce97267f0469cf0c9bd384488c91442bce.tar.gz
Revertcommits
Эта история про второй питон подразнесла нам графогенерацию . Нам придется этот коммит откатить. Суть проблемы в том, что генерация для 2го и 3го раньше была одной и той же командой. Ты сделал так, что команда стала разной, но аутпут этих двух команд одинаковый. Имя результата команды является ключом и сейчас берётся какая-то рандомная команда из двух. При этом команда влияет на UID и все UIDы питонячей протогенерации мигают. От фатальных проблем нас спасает только то, что protobuf-ы на самом деле одинаковые. И даже это не факт - сейчас ты патчишь какие-то рандомные либы включая таковые для 3го питона. Мы тут конечно редиски - мы в целом контролируем клэши аутпутов, но не в мультимодулях - там часто бывает что одна и та же команда оказывается в нескольких вариантах мультимодуля (потому что оно по дефолту сейчас так себя ведёт). Мы хотим это зачинить (сделать отдельный подмодуль под кодген и отселить всякие RUN_PROGRAM туда) - но это много работы и мы не успели. План такой: 1. мы откатываем твой фикс 2. отдельно стабилизируем раздельные команды генерации для 2го и 3го питона 3. накатываем обратно отревеченные тут правки. 916a5456c4e901ab2cda0841b4167e16397e83c4
Diffstat (limited to 'contrib/libs/libjpeg-turbo/jdatadst.c')
0 files changed, 0 insertions, 0 deletions