DeVM: виртуальная машина разработчика

Проблема

• Лицензия GPL на словах декларирует 4 свободы, но только на словах. А на деле 4 свобода такая недоступная, что на этой недоступности можно делать деньги, например, продавая X-Chat для Windows. В деле по продвижению DeVM важно делать акцент на «actually enabling the fourth freedom».
• Допустим, мы зашли на libre.adacore.com и скачали как скомпилированный код, так и все исходники. Допустим, каким–то чудом мы их собрали. А то, что у нас получилось, возьми да и не совпади 1:1 с бинарниками. Предположим, мы посмотрели на это сквозь пальцы и внесли какое–то желаемое изменение. Например, чтоб целые числа читались и писались в stream в big endian независимо от хост платформы. А потом вдруг обнаруживается, что где–то в модулях, связанных с поддержкой матриц, хоть мы их и не трогали, что–то сломалось потому что не так собрано. GMP, например, такой проект, который можно «не так собрать». А что может дать больше уверенности, что мы внесли только те изменения, которые хотели, чем возможность собрать бинарники 1:1, а потом поменять то, что нужно и собрать ещё раз?

Решение

• Нам бы хотелось решение подо все платформы, и чтоб с любой можно было пересобрать под любую другую. И, конечно, 1:1. Самым разумным решением видится использование упрощённой виртуальной машины разработчика (DeVM), эмулирующей x86-linux тем или иным способом. На linux и Mac OS X x86, предположим, мы используем vx32. На других архитектурах — внедряем QEMU. На Windows x86 нужно либо портировать vx32, либо тоже QEMU. Linux выбран так, как для него в изобилии представлены кросскомпиляторы под всевозможные целевые платформы. Таким образом, мы вне зависимости от реальной платформы запускаем эмулятор Linux, и уже с Linux кросскомпилируем на целевую платформу. Вместо того, чтобы распространять M компиляторов и M*(M - 1) кросскомпиляторов, мы распространяем M версий DeVM и M кросскомпиляторов, каждый из которых работает из DeVM
• Так как сборочные скрипты и собственно компиляторы очень уж любят обращаться к глобальному контексту, а именно, к путям типа /usr/include, /usr/local/include, в DeVM должен быть отличный контроль за виртуальной файловой системой. Стоит обратить внимание на Inferno-vx32
• В борьбе с глобальным контекстом неплохо преуспел nix package manager, неплохо иметь его в виду тоже.
• У некоторых утилит, например, tar, на выходе получается безликий поток октетов, но на входе некоторая директория, и для создания нужного tar может потребоваться использовать симлинки, которых возьми да и не окажись в основной OS в том же виде. В DeVM должен быть полный контроль за виртуальной файловой системой, что касается симлинков, а также расширенных атрибутов, например, Mac OS X, чтобы делать .dmg 1:1
• Должна быть неиллюзорная возможность выбрать файл и пересобрать его 1:1, автоматически подгрузив все зависимости в точности тех же версий. Достигнуть, например, можно, указав, каких Nar для nix package manager потребуются, их TTH и где их искать. Даже если по оригинальному адресу проект протухает, должна быть возможность подключать чужие копилки файлов, среди которых, если есть совпадение по TTH, можно будет вытянуть исходники и пересобрать 1:1.