Перспективні альтернативи зробити? [зачинено]

Я використовую make і makefiles вже багато років, і хоча концепція обґрунтована, реалізації є що бажати.

Хтось знайшов якісь хороші альтернативи, які б не ускладнювали проблему?

перевірити SCons . Наприклад, Doom 3 і Blender використовують це.

У мене багато друзів, які клянуться CMake за крос-платформну розробку:

http://www.cmake.org/

Це система збірки, яка використовується для VTK (серед іншого), це бібліотека C ++ з міжплатформеними прив'язками Python, Tcl та Java. Я думаю, що це, мабуть, найменш складне, що ви знайдете з такою кількістю можливостей.

Ви завжди можете спробувати стандартні автоінструменти . Файли автоматичного створення досить легко скласти, якщо ви працюєте лише на Unix і якщо дотримуєтесь C / C ++. Інтеграція є більш складною, а автоінструменти - далеко не найпростіша система.

doit - це інструмент python. Він базується на концепціях будівельних інструментів, але більш загальних.

• Ви можете визначити, наскільки завдання / правило є сучасним (не просто перевіряючи мітки часу, цільові файли не потрібні)
• залежності можуть динамічно обчислюватися іншими завданнями
• Діями завдання можуть бути функції python або команди оболонки

Деякі проекти GNOME переходять на waf .

Він заснований на Python, як і Scons, але також є автономним - отже, замість того, щоб вимагати, щоб інші розробники встановлювали ваш улюблений інструмент збірки, ви просто копіюєте окремий сценарій збірки у свій проект.

Я рекомендую використовувати Rake . Це найпростіший інструмент, який я знайшов.

Іншими хорошими інструментами, якими я скористався, якщо Рубі не твоя річ, є:

• AAP (Python)
• SCons (Python)
• Ant (Java, конфігурація в XML, досить складна)

Майте на увазі ninjaінструмент побудови (v1.8.2, вересень 2017), на який впливають tupі redo.

Генератор файлів збірки cmake(наприклад, для Unix Makefiles, Visual Studio, XCode, Eclipse CDT, ...) також може генерувати ninjaфайли збірки, починаючи з версії 2.8.8 (квітень 2012 р.), І, на жаль, ninjaзараз він навіть є інструментом побудови за замовчуванням, який використовується cmake.

Передбачається, що він перевершить makeінструмент (краще відстеження залежностей та паралелізація).

cmake- це вже усталений інструмент. Ви завжди можете вибрати пізніше інструмент побудови, не змінюючи файли конфігурації. Тож якщо в майбутньому буде розроблено кращу збірку, яка буде підтримуватися cmakeвами, ви можете зручно перейти до неї.

Зверніть увагу, що для покращення c / c ++ час компіляції іноді обмежений через заголовки, включені через препроцесор (зокрема, при використанні бібліотек лише заголовків, наприклад boost & eigen ), які, сподіваємось, будуть замінені пропозицією модулів (у технічному огляді c ++ 11 або врешті-решт c ++ 1y). Ознайомтесь із цією презентацією, щоб отримати докладні відомості щодо цього питання.

Я написав інструмент " саке", який намагався зробити написання подібних до файлів файлів дуже простим для читання та запису.

Це як би залежить від того, що ви намагаєтесь зробити. Якщо все, що вам потрібно, це цільові залежності у стилі make та виклик команди, то Make насправді є одним з кращих інструментів для завдання. :-) Граблі дуже приємні, але можуть бути незграбними в деяких простих випадках. Ant, звичайно, багатослівне місто, але він має кращу підтримку для побудови Java-подібних мов (Scala та Groovy в тому числі). Також Мураха доступний скрізь . Це головна причина, якою я її використовую. Оскільки він стабільно працює в Windows, насправді він навіть більш платформенний, ніж Make.

Якщо ви хочете керувати залежностями для Java-подібних бібліотек, Maven - це канонічний вибір, але мені особисто сподобався Buildr набагато краще. Це швидше і набагато легше налаштувати (воно базується на Rake). На жаль, це ще не все так широко, як Maven.

Система виготовлення Ruby називається рейком: http://rake.rubyforge.org/

Виглядає досить перспективно.

Завжди є Ant: http://ant.apache.org , який я особисто вважаю жахливим. Однак це фактичний стандарт для розробки Java.

Я все ще вважаю за краще робити, розглянувши купу альтернатив. Коли ви автоматично генеруєте залежності через компілятор або щось на зразок fastdep, вам не залишається багато чого зробити. Зокрема, я не хочу, щоб мій сценарій збірки був прив’язаний до мови реалізації, і мені не подобається писати матеріали в XML, коли доступні більш читабельні альтернативи. Інструмент, що викриває мову загального призначення, має переваги, проте інша інтерпретована мова цього не робить (afaik). Що не так із Make? може звернутися до вашої точки зору щодо відходу від марки.

/ Аллан

FlowTracer від RTDA - ще один хороший вибір, який я бачив у комерційному використанні у широкомасштабному середовищі (десятки тисяч робочих місць): http://www.rtda.com/flowtracer-design-flow-infrastructure-software

Він має графічний інтерфейс, який показує графік залежностей із кольоровими кодами для завдань та овалами для файлів. Коли кількість завдань і файлів стає високим, інструмент на основі графічного інтерфейсу, такий як FlowTracer, дуже важливий.

Початкова вартість встановлення вище, ніж Make. Існує крива навчання для налаштування вашого першого потоку, використовуючи його. Після цього він стає швидшим.

Я не впевнений, що ви задаєте тут правильне запитання.

Ви бажаєте спрощеної марки? У такому випадку вам потрібно змусити когось, хто дуже добре знайомий, створити серію (M | m) акефайлів, які спростять вашу проблему.

Або ви хочете розглянути основну технологію? Чи хочемо ми запровадити архітектуру типу проектування за контрактом, яка вбудована та впроваджена в дизайн коду? Або, можливо, сама мова, наприклад, Ada та її концепція специфікацій (інтерфейсів) та тіл (реалізації)?

Який напрямок ви домагаєтесь, безумовно, вплине на потенційні результати такого питання?

В основному, нові способи побудови систем лише з тих компонентів, які насправді змінилися, порівняно із прийняттям нових технологій, які мають такі механізми, вбудовані за проектом.

Вибачте, це не пряма відповідь. Просто хотів спробувати, щоб ти оцінив, яким шляхом ти хотів піти далі.

ура,

Роб