Ukrainian IT Blog

Час, коли в цивілізованому світі дешевше було найняти сотню негрів замість зробити ткацький верстат і навчити одну людину з ним працювати, давно минув. Ще пару десятиліть тому ледь не кожен працівник в сфері інформаційних технологій вважався митцем, творцем чогось надзвичайного, того, що не може зробити жодна інша людина в світі. Однак, час і прогрес не стоїть на місці, і поділ праці тому доказ. Замість тисяч самописних бібліотек виростають десятки, проте зручні та легкі; замість купи підходів до розв’язку задач виділяють одиниці, однак найефективніші; замість того, щоб вигадувати велосипед, використовують існуючі рішення, вносячи свій вклад в їх розвиток на ниві відкритих технологій. Ще донедавна програмісти збирали всі свої програми вручну або ж за допомогою самописних сценаріїв. Цей час пройшов.

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

Способи організації проектів, їх документації, юніт-тестів, тестів продуктивності, вражають своєю кількістю. Зазвичай кожен другий виробник більш-менш серйозного IDE, пакету програм для розробки, пропонує свій спосіб збереження файлів всередині проекту, організації процесу збирання, написання чи то генерація документації. Проблема постає у виборі інструментів, які допоможуть підвищити ефективність роботи та знизити часові витрати на її виконання. Сьогодні ми говоримо про системи збирання проектів.

В світі UNIX історично склалось, що більшість програм можна зібрати трьома командами:

$ ./configure
$ make
$ sudo make install

Цьому способу збирання та установки програм ми завдячуємо утиліті make. І хоча вона вже стара, як світ, однак досі популярна завдяки певній інертності розробників в виборі власних інструментів. Утиліта make оброблює т.з. Makefile – файл, що несе всі особливості процесу збирання. Однак вже тоді було зрозуміло, що писати їх вручну для великих проектів – досить марудна справа. І було винайдено autotools. Свого часу вони на порядок спростили визначення залежностей, встановлення додаткових параметрів компіляції, збирання та встановлення версій бібліотекам тощо. Таким чином, autotools на разі є найбільш відомою і популярною системою збирання програм під *NIX системи.

Та час ішов, і autotools стали здаватись дедалі більш заплутаними та складними. Проявились деякі недоліки: незважаючи на зручність в порівнянні зі збиранням вручну, написання навіть простих сценаріїв для генерації Makefile-у вимагали багато зайвої писанини. І ось вже нове покоління систем збирання з’являється на обрії. Одні з них слідують шляхом autotools, генеруючи сценарії для перевіреної часом make(QMake, CMake), інші ж розвиваються в напрямку власних сценаріїв збирання(SCons, Ant, Maven та ін.).

В цей же час проекти під сімейство ОС Windows зазвичай закріплені за проектами тих середовищ розробки, в яких вони були створені. При цьому неможливо зібрати проект не маючи відповідного середовища. З іншого боку, використання специфічних для кожного середовища файлів проектів покращує інтеграцію та інтерактивність при розробці. Ефективним способом виходу з цієї ситуації є взаємна інтеграція систем збирання та систем розробки. Так, на разі де факто стандартами для розробки Java проектів є використання Ant та Maven, управління якими інтегроване в більшість популярних середовищ розробки Java програм. Іншим способом вирішення проблеми є генерація файлів проектів для популярних середовищ розробки, що базуються на сценаріях збирання програм. Так, CMake дозволяє генерувати файли проектів для KDevelop, MS Visual Studio, звичайні Makefile, що дозволяє отримати готове до роботи середовище з найменшими витратами часу.

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

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

Таким чином, важливими вимогами до систем збирання є:

• простота в налаштуванні як простих, так і складних проектів
• висока гнучкість у налаштуванні при можливості використовувати параметри за замовчуванням
• інтеграція з популярними середовищами розробки
• кросплатформенність

В результаті вони

• надають можливість незалежного налаштування середовища розробки при незмінному принципі збирання
• дозволяють збирати програми та відслідковувати залежності незважаючи на відсутність IDE
• спрощують процес збирання проекту в цілому та окремих його частин
• зменшують часові затрати на перевірку та збирання проекту
• сприяють автоматизації процесу розробки

Ви ще не знаєте, навіщо системи збирання проектів? Тоді ми йдемо до вас!