[devel] re-writing GNU C; part1.3.1: how to apply

[Ivan Zakharyaschev <imz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5797 bytes --]

Добрый день!

Шлю записки о том, как начать применять cuglify/Process в работе с
какой-то "инородной" платформой FOO/Linux (без GCC). Скажем, в работе
по созданию порта Sisyphus на FOO/Linux. (mike@ уже видел эту часть.)

(FOO/Linux -- какая-нибудь платформа, где есть свой foo-cc, который в
чём-то похож на GCC, а в чём-то нет; и foo-cc патчить мы не можем.)

Есть несколько вариантов, как сделать первый шаг такого применения.

Один вариант -- более основательный и ценный для будущего, второй
вариант, который я могу представить (и уже опробовал на практике) --
проще и позволяет побыстрее увидеть результат компиляции.
(Третий вариант, который я пытаюсь сейчас осуществить и который
достижим побыстрее, чем первый основательный, опишу подробнее в
следующей части сообщения.)

Какую пользу ожидать от применения
==================================

Для делания порта на FOO/Linux пользу от применения cuglify/Process
можно получить уже сейчас, пока доделываю преобразователь C-кода.
Описываемые варианты применения сработают (но с частью вложенных
функций оно не справится -- разбирал примеры в devel: из патча
[на rpm][] и [на gpm][]).

Так незаметно для собирающего под FOO/Linux будет убрана часть проблем
с компиляцией (уже с помощью Process промежуточной готовности) и отлажена
схема применения cuglify/Process в этой работе. (Ещё вот что: возникла
необходимость переписывать опции компилятора, чтобы сохранять
задуманную мейнтейнером пакета семантику набора опций как у GCC --
опять же для гладкости сборки; чтобы такую гладкость побыстрее
достичь, я занимаюсь сейчас упомянутым третьим вариантом применения
Process на FOO/Linux, похожим по идее на distcc/ccache.)

При применении всегда можно брать (у меня или по инструкции)
свежесобранный Process под x86 с последним набором работающих фич.

[на rpm]: https://lists.altlinux.org/pipermail/devel/2016-January/200702.html
   (копия: [ann1_1.md](http://hub.darcs.net/imz/cuglify/browse/ann1_1.md))

[на gpm]: https://lists.altlinux.org/pipermail/devel/2016-January/200718.html
   (копия: [ann1_2.md](http://hub.darcs.net/imz/cuglify/browse/ann1_2.md))

Первый вариант:
===============

1. (придумать, как) соединить мой Process (который должен вести себя как
    cpp) так-как-он-есть-сейчас с gcc/clang/foo-cc (понять, куда воткнуть во
    внутренности вместо внутреннего cpp)
2. под x86 скомпилировать Process с помощью ghc с результатом на C (опции
    вроде via-C и т.п. -- надо мне повнимательнее посмотреть)
3. этот "Process.c" из 2 скомпилировать под FOO/Linux с помощью foo-cc
    (запуская там)
4. тестировать компиляцию исходников избранных пакетов (например,
    избранного коммита исходников rpm или gpm) связкой Process+foo-cc,
    придуманной в 1.


Второй вариант:
===============

* натравить Process на исходники избранного пакета, результат
   сохранить вместо оригинальных .c и собрать это foo-cc. (Не попробуешь
   -- сходу не скажешь, какие особенности вылезут из-за того, что
   результат Process будет не очень похож на оригинальные .c, потому
   что это вывод cpp.)

Во втором варианте кажется не важным, на какой машине запускать
Process, потому что тут есть это ручное подкладывание переработанных
исходников (и скопируем мы их с x86-машины или нет не меняет ход
действий). Но если поразмыслить:

конечно, cpp втащит includes, и пока что Process не обучен прятать
includes обратно; includes в любом случае разумно брать с FOO/Linux --
при этом это могут быть(?) не только стандартные места вроде
/usr/include/ и явно указанные места (которое мы можем довольно легко
подменить), но и внутренние штуки foo-cc. Так что x86-cpp не будет
знать, куда лезть (если специально не разобраться в этом)...

...ну хорошо, на вход Process можно (по крайней мере должно работать)
подавать .i, уже сделанные cpp (местным, на машине с FOO/Linux). Потом
Process их немного пожуёт, а полученные .i подложим вместо
.c-исходников на машину с FOO/Linux. (Это мне нравится больше, чем
обработка на x86-машине исходного .c, потому что тут всё чисто сразу.
Тут была мысль для удобства доделать Process на предмет вызова
cpp/foo-cc по ssh сразу, вместо локального cpp/gcc, чтобы облегчить
ход действий, но в итоге пошёл немного другим путём, "третьим".)

Развитие первого варианта и трудности реализации
================================================

Второй вариант хорош тем, что можно попробовать сразу. А первый
вариант потенциально доделывается до:

5. попросить нечто (то ли rpm, то ли hasher, то ли такой специальный
пакет сделать) подменять перед началом сборки /usr/bin/cc и всё такое
на связку Process+cc, придуманную в 1.
6. Собирать Process полностью на FOO/Linux, без x86 (собрав ghc с помощью
foo-cc и запуская его в режиме via-C) -- в этом нет первоочередной
практической необходимости (и можно будет заняться в последнюю
очередь, когда все фичи будут работать и пр).

В реализации первого варианта было бы эффективно покопаться мне -- с
ghc (via-C; хотя можно, наверное, обойти удалённым запуском Process),
а второй вариант доступен всякому.

автоматическая оценка исходных пакетов
--------------------------------------

Также первый вариант приближает к возможности запустить автоматическую
компиляцию списка избранных пакетов и потом посмотреть ошибки. Если
какой-то пакет не собирался раньше и собрался теперь, он будет интересным
успешным примером. (Можно их и автоматически классифицировать вызовом
Process -- имеется в виду, на то, с чем будет справляться Process на
разных этапах готовности, т.е. на pure, reader-only, r/w вложенные
функции, как в
[ann1_2.md](http://hub.darcs.net/imz/cuglify/browse/ann1_2.md).) Это
избавит от чтения вручную исходников всех проблемных пакетов в поисках
случаев, подходящих для тестирования и демонстрации работы Process в
той или иной степени готовности.

-- 
Best regards,
Ivan