Ninja: Подумайте о добавлении второго, «тяжелого» двоичного файла

Одна недоработанная идея - сделать основной код ниндзя «настоящей» библиотекой, а затем оставить обычный двоичный файл ниндзя достаточно маленьким и сфокусированным, а затем добавить где-нибудь второй двоичный файл (contrib / monster или что-то еще), который ссылается на библиотека ниндзя и добавляет все эти функции. Тогда этот двоичный файл может зависеть от самых разных вещей.

Это было бы круто. К вашему сведению, мы использовали ninja в базовой системе сборки bsb для проектов ReasonML / BuckleScript, в целом нам нравится производительность ninja, но она все еще кажется немного ограниченной без постоянного режима, я понимаю, что это может привести к увеличению deps или к уменьшению кросс-платформенный после введения дополнительных функций, но имеет смысл экспортировать ниндзя как библиотеку

какой-то настраиваемый интерфейс с интерфейсом передачи сообщений # 1210

Этот PR вообще не добавляет никакой зависимости от времени выполнения. Что именно вас там беспокоит?

Потому что, если это размер репозитория / дистрибутива Git или ремонтопригодность, наличие второго двоичного файла вряд ли поможет.

Я хотел бы предупредить, что многие проекты, использующие Ninja, не ожидают, что у пользователей будет предустановленный Ninja на их машинах, и такой проект предоставляет сценарий-оболочку, который загружает двоичный файл Ninja в дерево проекта, когда Ninja необходим. Если Ninja больше не является автономным исполняемым файлом, это МОЖЕТ сломать эти проекты.

например, загрузите по адресу https://chrome-infra-packages.appspot.com/dl/gn/gn/mac-amd64/+/latest используя Python: (python2) zipfile.ZipFile(io.BytesIO(urllib2.urlopen(url).read())).extract("gn", path="path/bin") , (python3) заменив urllib2 на urllib.request .

Следовательно, всегда необходимо создавать автономный исполняемый файл.

Я заинтересован в том, чтобы продвигать это вперед. Моя текущая мысль заключалась в том, чтобы сделать функцию main () для ниндзя очень маленькой и перенести все текущие функции внутри ninja.cc в границы библиотеки. Я собираюсь попытаться набросать некоторые из этих идей в коде, чтобы посмотреть, сможем ли мы превратить это в обсуждение различных технических компромиссов.

Я хотел бы предупредить, что многие проекты, использующие Ninja, не ожидают, что у пользователей будет предустановленный Ninja на их машинах, и такой проект предоставляет сценарий-оболочку, который загружает двоичный файл Ninja в дерево проекта, когда Ninja необходим. Если Ninja больше не является автономным исполняемым файлом, это МОЖЕТ сломать эти проекты.

например, загрузите по адресу https://chrome-infra-packages.appspot.com/dl/gn/gn/mac-amd64/+/latest используя Python: (python2) zipfile.ZipFile(io.BytesIO(urllib2.urlopen(url).read())).extract("gn", path="path/bin") , (python3) заменив urllib2 на urllib.request .

Следовательно, всегда необходимо создавать автономный исполняемый файл.

Если я когда-нибудь увижу, как дерево исходных текстов мутирует само себя, загружая и выполняя ложные неподписанные двоичные файлы, я, вероятно, больше не буду касаться этого программного обеспечения. Здесь отсутствует важный элемент дизайна.

@ johan-boule, нет, это не само программное обеспечение. Большой проект (например, Chromium) может использовать сценарий, который обрабатывает шаги установки для разработчиков, и сценарий установки имеет этот шаг для получения двоичных файлов.

@Leedehai Я просто напомнил, что большинство разработчиков не соглашаются терять контроль над тем, что загружается и выполняется на их машинах. Обычно это становится приемлемым, если для выполнения этой работы использовать надежный менеджер пакетов. Это часть конструкции системы, о которой я говорил.

Я создал предварительный PR для этой попытки на https://github.com/ninja-build/ninja/pull/1729. Я получил довольно много комментариев от jonesmz, но больше никого. Это может быть понятно, PR довольно длинный и извилистый, поскольку я понял структуру ниндзя. Я подумал, что для меня было бы полезно обобщить мой дизайн здесь для обсуждения.

1. Нам нужна система для ведения журнала, которая позволяет клиентам библиотеки захватывать сообщения журнала и отправлять их по-своему. jonesmz предлагает дизайн, похожий на boost, но ограниченный несколькими моментами:
   
   
   
   • Несколько бэкэндов, поэтому я могу динамически настраивать таргетинг на файлы журналов, вывод консоли или сервер журналов в сети, как я чувствую во время выполнения.
   
   
   • Динамические переменные, фиксируемые каждым оператором журнала, который может включать в себя имя текущей функции, текущую метку времени или что-то еще.
   
   
   • Легко заменить функционал с помощью макросов. Например, я могу предоставить свои собственные операторы ведения журнала, которые настраивают то, что регистрируется, путем определения макроса, который я вызываю.
   
   
2. Введение в пространство имен ниндзя. Это просто приятно, когда ты библиотекарь. Удаление «using namespace std» везде, где оно все еще используется в заголовках.
3. Разделение уровня ui отвечающего за анализ аргументов командной строки, на различные структуры для сохранения настраиваемого поведения. Передайте эти структуры в настраиваемые функции, чтобы изменить поведение.
4. Больше никакой логики для «дела идут плохо, выходите сейчас». Так что никакой функции ExitNow .
5. Создание класса Execution для хранения большей части логики, которая сейчас находится в ninja.cc/NinjaMain . Это исключает синтаксический анализ аргументов командной строки.
6. Удаление глобального состояния - некоторые помещаются в State , который можно сбросить при перестройке, некоторые помещаются в новый класс Execution (некоторые параметры, конфигурация), некоторые становятся статическими (debug_flags).
7. Введение общедоступных файлов заголовков. Они будут жить в inc/ninja/*.h . Это включает:
   
   
   
   • build_config.h
   
   
   • depfile_parser_options.h
   
   
   • logger.h
   
   
   • execution.h
   
   
   • ui.h
   
   
   • version.h
   
   
   • win32port.h
   
   

Я собираюсь начать новую ветку, повторно внедряя мои изменения поверх master, пытаясь прояснить мои намерения. Мне бы хотелось, чтобы у сопровождающих было достаточно обсуждения моего подхода, чтобы быть разумно уверенным, что мой подход в правильном направлении.

@nico @jhasse приемлемо ли для вас это направление? Если нет, что бы вы хотели увидеть?

Незначительное исправление - пункт 6, во флаги отладки ничего не добавляется, а статика удаляется из них и становится членами данных либо State либо Execution .

@jhasse или @scivision кажетесь наиболее активными сопровождающими, интересует ли эта тема кого-то из вас?

Я просто пользователь ниндзя. Я еще не чувствовал потребности в таком уровне перестройки ниндзя, хотя я могу хотя бы поверхностно понять предлагаемые преимущества и необходимость в них.

Спасибо, что обратились к @scivision , моя ошибка, я увидел, что вы пометить @nico, чтобы найти сопровождающего.

Учитывая, что никто не участвовал в этом разговоре и не проявлял интереса, возможно, они согласны с вами и у них нет времени сказать об этом.

Я тоже не чувствовал необходимости в этом. Хотя меня очень интересует # 1600.

Хорошо, спасибо за ответ. @jhasse у вас есть место, где вы бы предпочли провести это обсуждение? Предлагаемый мною дизайн позволит создать «тяжелый» двоичный файл. Это также позволило бы создать другой интерфейс, но это будет делать это несколько иначе, чем было первоначально предложено collincross.

Внесение соответствующих архитектурных изменений, позволяющих использовать базу кода Ninja в качестве реальной библиотеки (даже статически связанной), резко упростило бы реализацию # 1600.

Лично меня очень интересует создание библиотек для интеграции в IDE и другие инструменты (анализ файлов ниндзя и т. Д.) Без необходимости вызывать внешний двоичный файл.

Этот вопрос - подходящее место для обсуждения этого.

Хорошо, на данный момент я ищу:

1 - «Да, этот план выглядит хорошо на высоком уровне, продолжайте, и я рассмотрю детали, поскольку они доступны, чтобы убедиться, что это то, что мы хотим сделать для ниндзя».
2 - «Нет, мне не нравится этот план, я бы предпочел увидеть что-то вроде следующего:"

Я бы хотел получить это от сопровождающего. @jhasse, не могли бы вы уточнить, какой из этих двух ответов лучше соответствует вашему мнению? Я считаю, что этот дизайн поддерживает # 1600, который вас очень интересует. Согласны? Хотите посмотреть что-нибудь еще для # 1600?

3 - «Насколько я могу судить, план выглядит хорошо. Но для меня есть другие вопросы, которые меня больше интересуют, и у меня нет достаточно времени, чтобы рассмотреть изменения».

Я не особо разбирался в том, как изменения помогут # 1600. Насколько я понимаю, он бы его заменил.

Он заменил бы его. В # 1600 есть небольшая реализация части встроенных протоколов, позволяющая передавать данные в отдельный процесс внешнего интерфейса. @nico в какой-то момент (в # 1210) был против добавления protobuf в ниндзя. Нико предложил создать два отдельных двоичных файла: легкий, который является ниндзя по умолчанию в выпуске, и тяжелый, который может иметь такие вещи, как protobufs и иметь настраиваемый вывод внешнего интерфейса.

Цель моего дизайна здесь - сделать это архитектурно выполнимым. Я пытаюсь определить базовую библиотеку ниндзя и ее интерфейс. Это позволит проекту ниндзя создать тяжелый двоичный файл и легкий двоичный файл, оба примерно в одной и той же библиотеке. Это также позволит потребителям проекта связываться с самой библиотекой для дальнейшей настройки поведения.

Изначально я думал, что PR будет хорошим способом обсудить общий дизайн. Я не получил никаких отзывов (кроме jonesmz, который был классным). Итак, теперь я пытаюсь провести обсуждение на высоком уровне, прежде чем затрачивать больше усилий на код.

С точки зрения сопровождающих, проще всего, если я создам весь код, а вы просматриваете его только после того, как он будет завершен. С моей точки зрения, это опасная трата времени, поскольку ответ может быть «нет, не хочу ничего подобного». Я надеюсь, что специалисты по сопровождению ниндзя могут пойти мне навстречу и обсудить со мной, что они готовы принять, прежде чем я уделю больше времени самому коду.

Хорошо, я дал на это несколько недель и попытался связаться с сопровождающими, используя все доступные мне средства. Я собираюсь считать это усилие «недостаточно интересным, чтобы беспокоиться о его обсуждении» с точки зрения сопровождающих.

Я собираюсь начать обсуждение с сопровождающими в проекте splinter, чтобы узнать, заинтересованы ли они в чем-то подобном.

Если придут какие-нибудь сопровождающие и захотят окончательно прокомментировать это, я буду признателен за ясность.