[Harvester 0]

Получил в наследство проект программно-аппаратного комплекса (ПАК).

Во время сборки "дистрибутива" выполняется куча самых разных операций:

• компиляция ассемблерных исходников
• компиляция служебных утилит для DOS и Windows
• сборка DLL
• сборка прошивки ПЛИС
• компиляция прошивки NIOS
• копирование/удаление файлов и пр.

Часть используемых средств - 16-битные и выполняются из-под DOSBOX.

Сейчас это все "автоматизировано" посредством кучи bat-файлов.

Список ПО в википедии (https://en.wikipedia.org/wiki/List_of_build_automation_software) изучил, но глаз ни за что не зацепился.

Вроде бы под мои требования подходит Visual Build Professional, но она платная и какая-то монструозная.

Может кто-нибудь посоветует более-менее распространенную систему сборки, не привязанную к конкретному языку/фреймворку?

 

[andrew_b 14]

Наисамая распространённейшая -- make.

[kolobok0 0]

2 hours ago, Harvester said:

... распространенную систему сборки, не привязанную к конкретному языку/фреймворку?

 

То что Вы спрашиваете относится к части девопса и должно по идее интегрироваться в общий схемотоз работы разработчика-коллектива-подразделения с учётом интеграции до и после этого процесса.

Т.к. ваша задача сборки не висит в воздухе - то нужно исходить из того что Вы юзаете в качестве хранения исходников, планы на развитие, общее понимание этой механики внутри коллектива и ... и много чего ещё.

Например если у вас гитлаб - то наверное можно рассмотреть его родное CI/CD (правда халявный вариант имхо - сыроват). Если нужна просто молотилка которая на все случаи жизни - то возможно имеет смысл заюзать CI типа Jenkins-а или похожее. Но это не сам компилятор или скрипт, это больше облочка над шэлами-мавами-скриптами-батч_пакетами и прочая шняга. Причём за минимум телодвижений можно сделать сразу понты - печать, натификация, интеграция, графики, логи, артифакты и прочая хрень. Но надо вникнуть в дух этой фигни, с наскока не получиться увы...

И ещё... То что Вы перечислили - мааааалая часть того, что пои идее должно происходить на фазе до-во_время-и_после_сборки. Если почитать популярные словосочитания TDD, CD, CI и т.д. и т.п. то сама по себе эта ниша досfтточно глубокая и широкая. Не использовать опыт ранее накопленный - проигрывать на рынке. Использование - траты на изучение или получение как результата. тут вот всё индивидуально.

и ещё... Если Вам кажется, что всё что написал выше это перебор - то прочтите этот пост через 5-10 инсталяций вашего продукта у крупных заказчиков, когда возрастут объёмы, время сократиться а функционала будет нарощено на порядки). Думаю Вы уже не будете столь категоричны :)

[kolobok0 0]

15 minutes ago, andrew_b said:

 make.

+1
ну.... в общем-то да. я что то воспринял как более фундаментальный заход на тему...
make или если универсальный - cmake так-же не плохая игрушка = справится с перечисленными ТС задачами...

[Harvester 0]

30 minutes ago, kolobok0 said:

+1
ну.... в общем-то да. я что то воспринял как более фундаментальный заход на тему...
make или если универсальный - cmake так-же не плохая игрушка = справится с перечисленными ТС задачами...

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

[kolobok0 0]

10 minutes ago, Harvester said:

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

make или cmake(для универсальной, под разные оси) предназначен как раз для операций компилирования, задания рабочих каталогов, зависимостей файлов от результата, вызов команд на сборку и других операций - всё это позволяет делать. попроще make конечно же, точнее сказать он прост в настройках - всё ровно как лом. но cmake более прост в запуске если понять логику по сэмплам. т.е. если с программированием на ты или около - то можно смело поюзать cmake. какие-то настройки cmake (более глубокие) - имхо покопаться немного придёться. Но зато он много чего делает интуитивно на автомате. 1) ищит все компиляторы что у  вас есть на машине 2) понимает почти на автомате что прилинковывать и как собирать. 3) и т.д. ...

знакомиться лучше с любым опен-соурс мультиплатформенным проектом собираемый cmake. вам понравится :)

В не зависимости make or cmake основные вехи
1) описание в текстовом файлике зависимостей исходников от таргет целей(получаемых объектников и уже объектники от бинаря)
2) настройка правильных вызовов необходимых компиляторов-линковщиков
3) дополнение необходимых телодвижений по ходу пьесы - копирование, создание, удаление...make только у вас будет заточен на конкретную ось - например форточки...

Изменено 14 декабря, 2018 пользователем kolobok0

[Grizzly 0]

А почему cmake более универсальный?) Это же не сборочная система, а генератор Makefile'ов. Таким образом, make позволяет сделать то же самое и даже больше. make ведь есть под Win. Вручную придется, конечно, определять некоторые пути и переменные в зависимости от ОС, зато более фундаментальная штука.

цель зависимость

<Tab> правило

[dxp 33]

SCons.

QBS.

[Harvester 0]

1 hour ago, dxp said:

SCons

Тоже обратил на него внимание. :)

Основной вопрос, который мне не дает покоя - стоит ли овчинка выделки?

Была куча bat-файлов, станет куча make-файлов. Есть ли в этом смысл?

 

[AlexandrY 3]

cmake + ninja

Стоит посмотреть хотя потому что построение  на порядок ускоряется.
Т.е. можно ожидать, что  ninja в 10 раз быстрее соберет чем скажет такая визуальная IDE как Visual Studio. 

 

[Grizzly 0]

3 часа назад, dxp сказал:

QBS

Qt отказались от неё: https://www.opennet.ru/opennews/art.shtml?num=49519

16 минут назад, AlexandrY сказал:

ninja в 10 раз быстрее

Это только для пересборки очень большого проекта при изменении одного (или нескольких) файлов. ТС собирает "дистрибутив". Как я понимаю, это однократная сборка на каждом целевом месте.

[Grizzly 0]

1 час назад, Harvester сказал:

Была куча bat-файлов, станет куча make-файлов. Есть ли в этом смысл?

 

Философский вопрос ;) Насколько хорошо и понятно для вас написаны bat файлы? Необходимо дальше развивать эту систему?

Нужно взвесить как следует, что окажется затратнее по времени.

[kolobok0 0]

15 hours ago, Grizzly said:

А почему cmake более универсальный?) Это же не сборочная система, а генератор Makefile'ов. ...

Пока пишешь на одном писюке, один проект, с одним функционалом - не заметно. как только вылезаешь из штанишек - то начинаешь упираться в компиляторы, оси, инструментарий и прочую хрень. Лучше уж один раз изучить инструментарий и "забыть его", чем всякий раз дописывать очередной костылёк под ту или иную изменившуюся хрень. Более чем один комп, выросла команда - кто под форточками сидит, кто предпочитает линукс. Кто пафосно запускает студии кто правит в нотепаде код. Кто то возится с отладкой - кто то "пишет без багов", кто то предпочитает TDD - кто то об этом даже не задумывался. В cmake вы указываете что вам нужно получить, а как - это проблемы cmake. Он корректно всё подготовит для "любой" оси. И собственно в окружении по использованию инструментария у вас ничего собственно и не измениться. что уменьшает человеческий фактор и экономит часы...

 

как то так

ЗЫ

По началу я так-же скептически относился к этому. Попробовал - профит очевиден. Проект под форточки и линукс...

Изменено 16 декабря, 2018 пользователем kolobok0

[AlexandrY 3]

55 minutes ago, kolobok0 said:

а как - это проблемы cmake. 

Кто не знает, напомню, cmake - это мета-построитель. 
Кроме него нужно сразу указать непосредственно построитель или несколько построителей.
Как вариант - make, autotools, Eclipse, VS  и т.д. 
Так вот эти построители бывают медленные и быстрые. Ninja - самый быстрый.

Кроме того нужно проверить есть ли у cmake необходимый для проекта какой-то особенный  генератор (выполнить  cmake --help )
Может оказаться что генератора то и нет.
Скажем cmake мне совсем не поможет если надо собрать проект под IAR или Keil. 
Т.е. есть довольно жесткая сегрегация на коммерческие и опенсорсные инструменты. 

[Grizzly 0]

18 минут назад, AlexandrY сказал:

Keil

У нас проект для armcc из Keil был на make написан. Для Win и Linux через wine.

Наверное, все же попробую ninja вместо make на каком-нибудь реальном своем проекте. Так-то только какие-то примеры запускал с ним.