Чи автоматичне автоматичне налаштування та автоматичне підключення є стандартним способом компіляції коду?

Я іноді компілюю програми з джерела і я або використовую:

./configure
make
sudo make install

Але нещодавно я натрапив на те, ./autogen.shщо генерує конфігурацію та робить сценарії для мене та виконує їх.

Які ще існують методи оптимізації компіляції C / C ++ / C # (mono)? Зробити здається трохи старим. Чи є нові інструменти там? З огляду на вибір, який я повинен використовувати?

Autoconf та Automake були розроблені для вирішення еволюційної проблеми Unix.

По мірі того, як Unix розвивався в різні напрямки, розробники, які хотіли, щоб портативний код писали так:

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

Оскільки Unix був роздвоєний у різних реалізаціях (BSD, SystemV, багато виробничих виделок, а пізніше Linux та інших Unix-подібних систем), розробникам, які хотіли написати переносний код, стало важливо писати код, який залежав не від конкретної марки операційної системи , але щодо функцій, які піддаються операційній системі. Це важливо, тому що версія Unix вводить нову функцію, наприклад, системний виклик "відправити", а пізніше інші операційні системи приймають її. Замість того, щоб мати спагеті з кодом, який перевіряв на бренди та версії, розробники почали досліджувати функції, тому код став:

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

Більшість файлів README для компіляції вихідного коду ще в 90-х роках загострені розробниками для редагування файлу config.h та зауважують, що належні функції доступні в системі, або вони доставлять стандартні файли config.h для кожної тестованої конфігурації операційної системи.

Цей процес був як громіздким, так і схильним до помилок, і таким чином став Autoconf. Ви повинні думати про Autoconf як про мову, що складається з команд оболонки зі спеціальними макросами, які змогли замінити людський процес редагування config.h інструментом, який перевіряв операційну систему на функціональність.

Зазвичай ви записуєте код зондування у файл configure.ac, а потім запускаєте команду autoconf, яка збирала б цей файл у виконувану команду налаштування, яку ви бачили використаною.

Отже, коли ви запускаєте, ./configure && makeви перевіряли функції, наявні у вашій системі, а потім будували виконуваний файл із встановленою конфігурацією.

Коли проекти з відкритим кодом почали використовувати системи управління вихідним кодом, було доцільно перевірити файл configure.ac, але не результат компіляції (налаштування). Autogen.sh - це лише невеликий скрипт, який викликає компілятор autoconf з потрібними для вас аргументами команд.

-

Автоматика виросла також із існуючої практики у громаді. Проект GNU стандартизував звичайний набір цілей для Makefiles:

• make all створив би проект
• make clean видалить усі зібрані файли з проекту
• make install встановив би програмне забезпечення
• такі речі, як make distі make distcheckпідготували б джерело до розповсюдження та підтвердили, що результатом був повний пакет вихідного коду
• і так далі...

Побудова сумісних грифів стала обтяжливою, оскільки було багато плит, які повторювались знову і знову. Тож Automake був новим компілятором, який інтегрувався з autoconf та обробив "вихідний" Makefile's (з ім'ям Makefile.am) у Makefiles, який потім може подаватися до Autoconf.

Ланцюжок інструментів automake / autoconf фактично використовує ряд інших допоміжних інструментів, і вони доповнюються іншими компонентами для виконання інших конкретних завдань. У міру того, як складність виконання цих команд зростала, потреба в готовому для запуску скрипті народилася, і саме звідси походить autogen.sh.

Наскільки мені відомо, Gnome був проектом, який представив використання цього помічника скрипта autogen.sh

У цій галузі є два "великі гравці"; Cmake та GNU Autotools.

• GNU Autotools - це спосіб GNU робити речі і орієнтований на * nix. Це свого роду система мета-збирання, що надає набір інструментів, які генерують конкретні конфігурації та створюють файли для того, що ви намагаєтесь зробити. Це допомагає вам вносити більше змін у свій код без необхідності безпосередньо маніпулювати системою збирання, а також допомагає іншим будувати ваш код таким чином, який ви не розробляли для цього - під * nix.

• Cmake - це крос-платформний спосіб робити речі. Команда Cmake будує програмне забезпечення на безлічі багатьох різних способів: GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux. Якщо ви взагалі переймаєтесь переносимістю кодової бази, це шлях.

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

У Ruby також є така система мета-побудови під назвою Rake, яка досить крута сама по собі, і дуже зручна для тих, хто вже знайомий з Ruby.

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

Якщо ви використовуєте C # / Mono, ви можете використовувати msbuild (файли .sln / .csproj, які використовуються MonoDevelop та Visual Studio) для управління всім процесом збирання.

Потім можна або створити з MonoDevelop, або запустити xbuildкоманду в улюбленому терміналі (найкраще працює в Mono> = 2.6). Це надзвичайно просто і вимагає майже ніякої роботи з вашого боку, тому що MonoDevelop буде обробляти файли msbuild для вас, і вам не потрібно буде їх редагувати, якщо ви не хочете налаштувати речі, що перевищують те, що інтерфейс MonoDevelop може зробити для вас.

Я не знайомий з тим, як люди, які залежать від msbuild, обробляють установки для своїх проектів, але ви завжди можете це запитати. ;-)

Для C # ви можете використовувати xbuild (та msbuild на windows), який будуватиме проект з ваших файлів проекту.