Как стать автором
Обновить

Комментарии 19

Не, ну ладно, Make вам, по понятным причинам, не подошел. Но сейчас же так много билдовых систем. Чем они-то вам не угодили? Зачем городить еще одну, которой никто кроме вас пользоваться не будет?
А почему нет? Для каждого дела свой инструмент, не всегда удобно пользоваться универсальными швейцарскими ножами, же.
Мейтенс, суппорт, комьюнити, да и расширяемость всегда не лишняя. Ну и сторонние инструменты, как правило, гораздо-гораздо стабильнее. А ваша билдовая система даже не является самостоятельным проектом. Этакое решение в стиле «ad hoc».
Можете назвать несколько?
НЛО прилетело и опубликовало эту надпись здесь
Для данного случая видимо наиболее оптимальным выглядит использование чего-то типа CMake или SCons. Если хотелось бы генерить конечные make-файл, то можно заюзать premake. Если уж прижмет настолько, что прям хочется свою кастомную систему сборки (ну там на основе JSON), то самым оптимальным будет использование в качестве платформы чего-то типа waf-devel.blogspot.com/2010/12/make-your-own-build-system-with-waf.html где вы пишите только минимальную обвязку, а обо всем остальном (вычисление зависимостей, поддержка компиляторов) заботятся другие люди.

Ну а вообще билдовых систем на всякий вкус много en.wikipedia.org/wiki/Category:Build_automation
Из перечисленного, лучше всего под описанные задачи (среди которых «Система сборки не тянула за собой уйму зависимостей») подходит waf, но и он тянет за собой python.
Правило буравчика: если для своего проекта вы изобретаете собственный язык, значит, вы что-то делаете не так.
Это еще почему? Так же можно сказать если вы изобретаете собственное API вы делаете не так. Но изобретают все.
В вашем случае странно изобретение собственного сборщика. Обычно это признак проблемы «я не в силах одолеть документацию».

Допустим, ваша система умеет что-то, что не умеют другие, или что она делает что-то ощутимо быстрее или лучше, чем другие. В этом случае уже существут множество языков для вашей задачи. JSON, YAML, Lua и др. Изобретение собственного языка в этом случае — обычно признак проблемы «хочу показать свою крутизну».

Итого возникают вопросы:
1) Чем ваша система превосходит существующие? Что она умеет делать нового, что она умеет делать лучше? («Интерфейсы»?)
2) Чем ваш язык превосходит существующие? Что он умеет делать нового, что он умеет делать лучше?

И не примешивайте API. API — это взаимодействие с вашим же приложением. Здесь чужими наработками нечасто удастся воспользоваться.
Соглашусь изобретение крайне нового языка спорно, но использование других сплошь и рядом. Наверное для сборки модулей уже давно все используют XML + какие-то валидаторы (или unit test). Действительно языков хватает, просто в начале нужно определить цель языка, поддержка выражений и т.п. и подобрать подходящий из существующих.
>> если для своего проекта вы изобретаете собственный язык, значит, вы что-то делаете не так.
То есть создание языка наверное не самое лучшее решение, но применение специальных языков с некоторыми ограничениями — самое-то.
Я вот тоже не люблю когда с каждым новым инструментом приходится изучать новый язык, но ребята свою операционную систему сделали, чего уж там язык то создать :)
Ну а инструмент однозначно стоит попробовать.
Пожалуй, не соглашусь с вами.

Зачастую написать свой простенький DSL — это наиболее оптимальный вариант. Зачем мне универсальный комбайн, если большинство его возможностей вообще не используется?

Перечисленные вами языки (JSON, YAML, Lua) наиболее уместны в случае, когда само приложение целиком реализовано на соответствующих языках (JavaScript, Lua, ...). Да, можно использовать сторонние библиотеки для разбора, но это будет еще одной лишней зависимостью.

Изобретение собственного языка в этом случае — обычно признак проблемы «хочу показать свою крутизну».
Расскажите об этом создателям JetBrains MPS и Eclipse Xtext.
Знаете, честно — синтаксис языка «Ни Ява, ни мясо».
Почему я скорее всего не буду пользоваться такой системой?
Я не хочу разбираться в еще одном языке. Поэтому лично я не люблю make и qmake.
Именно за понятный, интуитивный язык, не велосипедный, я полюбил QBS.
Сейчас все руки не доходят написать продолжение статьи, воюю с разработчиками насчёт патчей…

Еще одна проблема — исходники. С qbs я скачал, и в течение пары часов разобрался как внедрить нужные фичи. Код превосходно структурирован, как QtCreator например. Читать одно удовольствие.
Такого же удовольствия от чтения, например
int ramdisk_create(void *mkfs_params) {
        node_t *ramdisk_node;
        mkfs_params_t *p_mkfs_params;
        ramdisk_params_t *ramd_params;

        p_mkfs_params = (mkfs_params_t *)mkfs_params;

        if (NULL == (ramdisk_node = vfs_add_path(p_mkfs_params->path, NULL))) {
                return -EBUSY;/*file already exist*/
        }

        ramd_params = ramdisk_info_alloc();
        ramdisk_node->attr = (void *) ramd_params;

        if(NULL == (ramd_params->p_start_addr =
                        page_alloc(p_mkfs_params->blocks))) {
                return -ENOMEM;
        }

        strcpy ((void *)&ramd_params->path, (const void *)p_mkfs_params->path);
        ramd_params->size = p_mkfs_params->blocks * CONFIG_PAGE_SIZE;
        ramd_params->blocks = p_mkfs_params->blocks;

        strcpy ((void *)&ramd_params->fs_name,
                        (const void *)p_mkfs_params->fs_name);

        return 0;
}


уже не получишь. Такой код хорошо отлаживать только его автор, наверное. Я вот например, в ядро навряд ли патч смогу оформить.
Немного промазал с комментарием:
Спасибо за критику, но какое отношение к системе сборки Mybuild имеет приведенный вами код на Си?
Прошу прощения, был невнимателен (у меня конец рабочего дня). Код Embox к вашему проекту конечно не имеет отношения.
Но в остальном моя позиция та же — я хочу понятный, уже известный, максимально прозрачный язык для написания конфигов. QML под это определение попадает.
т.е. к системе сборки. я имел ввиду. пойду спать пожалуй…
Спасибо за критику, но какое отношение к системе сборки Mybuild имеет приведенный вами код на Си?
А я могу только поддержать ребят. Я не вижу ничего плохого в изобретении собственных микро-языков, разве не на этой идее построена половина UNIX?
Наличие собственной системы сборки, помимо очевидных недостатков, имеет и значительные преимущества: её можно развивать именно в том направлении, которое действительно важно, и принимать именно те технихнические решения, которые наиболее удобны и логичны в конкретной ситуации, не гонясь за абсолютной универсальностью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий