Как вести разработку нового таргета?

  1. 6 г. назад

    Для установки нового таргета в Monkey необходимо не только новая директория в /targets, но и добавление Builder'a в исходный код transcc. Вижу, что создатели таргетов поступают просто, например в OUYA предлагается самому проделать все эти действия. Не очень удобно, не только для пользователя, но и вообще для разработки. И такой таргет невозможно «подцепить» в виде подмодуля в git.

    Что если сделать форк официального репозитория Monkey , переименовать его соответствующие (monkey-имятаргета) и в него добавить собственный таргет? Возможно это будет удобнее:
    + позволяет более глубоко интегрировать таргет в Monkey, если это необходимо. Например, файл /src/transcc/builders/makemeta.cpp существуют только в C++ версии, а если захочется сделать версию для другого ЯП, то без изменений вне папки /targets не обойтись.
    + есть возможность объединить несколько таргетов в одном локальном репозитории, без ручной работы по изменению исходных кодов Monkey
    — но не очень ясно, в какой ветке Monkey вести разработку таргета? master или develop?

    Как правильно делать?

  2. devolonter

    5 Jun 2014 Администратор
    6 г. назад исправил devolonter

    В случае с неофициальным таргетом OUYA мне если честно не совсем понятно зачем нужно пересобирать билдер учитывая, что он ничего не добавляет, а просто наследуется от AndroidBuilder. Чтобы новый таргет отобразился в списке доступных, свой компоновщик добавлять не обязательно. Просто выставить #TARGET_BUILDER=«android» Другое дело, что часто действительно нужны определенные действия для сборки.

    По поводу форка. Держать его синхронизированным довольно муторно. Придется каждый раз делать fetch, а потом мерджить с изменениями в основной ветке. При этом вести свои изменения в ветках master и dev не получится, т.к. рано или поздно при синхронизации случится конфликт. Т.е. нужно держать отдельную ветку для таргета и постоянно мерджить его с master или develop. Тогда можно будет сделать один форк и каждый таргет сделать отдельной веткой. Но все это жуткие костыли…

    В идеале было бы здорово разбить Monkey на подмодули и иметь несколько репозиториев со строго разграниченным функционалом. Но Марк, скорее всего, никогда этим заморачиваться не будет, т.к. он не особо расположен к коллективной разработке. Он даже мерджит некоторые сторонние пулл-реквесты вручную, а не средствами git. Так что особых подвижек в этом плане ожидать не стоит.

    Выход один — делать все силами сообщества и надеяться, что это кто-то оценит :) На самом деле, мне бы хотелось чтобы все так и было. Но пока я не видел подобного стремления в сообществе Monkey.

или зарегистрируйтесь чтобы комментировать!