Чому ніхто не використовує make для Java?

Майже про кожен проект Java, який я бачив, або використовує Maven або Ant. Вони є прекрасними інструментами, і я думаю, що майже будь-який проект може їх використовувати. Але що коли-небудь траплялося зробити ? Він використовується для різноманітних проектів, що не є Java, і може легко працювати з Java. Звичайно, вам доведеться завантажити make.exe, якщо ви використовуєте Windows, але Ant і Maven також не постачаються разом із JDK.

Чи є якийсь фундаментальний недолік з make при використанні з Java? Це лише тому, що Мураха та Мейвен написані на Яві?

Принциповою проблемою із Make and Java є те, що Make працює за умови, що ви вказали залежність, а потім правило для усунення цієї залежності.

З базовим C, який, як правило, "для перетворення файлу main.c в файл main.o, запустіть" cc main.c ".

Це можна зробити в Java, але ти швидко чогось навчишся.

Переважно, що компілятор javac повільно запускається.

Різниця між:

javac Main.java
javac This.java
javac That.java
javac Other.java

і

javac Main.java This.java That.java Other.java

це ніч і день.

Посилюють це з сотнями занять, і це стає просто нездійсненним.

Потім ви поєднуєте це з тим, що java, як правило, організовується як групи файлів у каталогах, порівняно з C та іншими, які мають тенденцію до більш плоскої структури. Make не має великої прямої підтримки для роботи з ієрархіями файлів.

Зробити також не дуже добре для визначення того, які файли застаріли, на рівні колекції.

Що стосується Ant, він перегляне і підсумує всі застарілі файли, а потім скомпілює їх за один раз. Make просто зателефонує у компілятор Java на кожен окремий файл. Зробити НЕ для цього потрібно достатньо зовнішнього інструментарію, щоб дійсно показати, що Зробити не зовсім до цього завдання.

Ось чому піднялися такі альтернативи, як Мураха та Мейвен.

Поважна makeпрограма досить добре обробляє окремо складені мови, такі як C та C ++. Ви компілюєте модуль, він використовує #includeдля витягування в текст інших файлів, що включають, і записує один об'єктний файл як вихід. Компілятор - це дуже одноразова система з окремим кроком зв’язування для прив’язки об'єктних файлів до виконуваного двійкового файлу.

Однак у Java компілятор повинен фактично компілювати інші класи, які ви імпортуєте import. Хоча можна було б написати щось, що генерувало всі необхідні залежності від вихідного коду Java, щоб це makeбудувало класи в правильному порядку один за одним, це все одно не оброблятиме випадки, такі як кругові залежності.

Компілятор Java також може бути більш ефективним, кешуючи зібрані результати інших класів при компілюванні подальших класів, які залежать від результатів вже складених. Таке автоматичне оцінювання залежностей насправді неможливо makeсамостійно.

Питання заснований на невірному припущенні: нетривіальне число розробників робить використання make. Див. Інструменти побудови Java: Мураш проти Мейвена . Щодо того, чому розробник не користувався б make: багато розробників або ніколи не використовували make, або використовували його і ненавиділи його вогнем, який горять гарячіше тисячі сонців. Як такі, вони використовують альтернативні інструменти.

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

JAVA_FILES:=$(wildcard *.java)
#
# the rest is independent of the directory
#
JAVA_CLASSES:=$(patsubst %.java,%.class,$(JAVA_FILES))

.PHONY: classes
LIST:=

classes: $(JAVA_CLASSES)
        if [ ! -z "$(LIST)" ] ; then \
                javac $(LIST) ; \
        fi

$(JAVA_CLASSES) : %.class : %.java
        $(eval LIST+=$$<)

Усі інші відповіді про технічні достоїнства кожного є вірними. Antі Mavenможе підходити більше до Java, ніж робити, або, як вказує Хенк Гей, вони можуть не робити :)

Однак ви запитали, чи не має значення, що Мураха та Мейвен написані на Яві. Хоча в StackOverflow такі думки не враховуються (закриті! Не пов'язані з програмуванням! І т. Д.), КУРСУ, ЩО ЧАСТИНА ЧОГО. На рейках ми використовуємо Rake, C чуваки використовують make, а на Java використовуємо Ant та Maven. Хоча це правда, що розробники Ant або Maven будуть піклуватися про розробника Java, можливо, краще за інших, є також інше питання: у що ви пишете завдання Ant? Java. Якщо ви розробник Java, це легко підходить.

Так, так, частина цього полягає у використанні інструментів, написаних мовою, яку ви використовуєте.

Мураха і пізніше Мейвен були покликані вирішити деякі головні болі, викликані Make (створюючи нові в процесі). Це просто еволюція.

... Незабаром після цього кілька проектів Java з відкритим кодом зрозуміли, що Ant може вирішити проблеми, які вони мали із Makefiles ....

З http://ant.apache.org/faq.html#history

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

Основна перевага, яку вона має, - це можливість інтегруватися з java.

Я думаю, подібна історія була б, rakeнаприклад.

Однією з найважливіших проблем, яку вирішили Maven (і налаштування мурашок, що підтримуються Ivy), є автоматизоване вирішення залежностей та завантаження ваших банок залежностей.

Я вважаю, що найбільш вірогідне пояснення полягає в тому, що кілька факторів стримували використання make в спільноті Java протягом критичного періоду часу (кінець 1990-х):

1. Оскільки Java охоплює декілька платформ, програмісти Java взагалі не були настільки спритні в інструментах Unix, як програмісти, як правило, обмежені в середовищі Unix (наприклад, програмісти C і Perl). Зауважте, що це ЗАГАЛЬНО. Без сумніву, є і були обдаровані Java-програмісти з глибоким розумінням Unix.
2. Отже, вони були менш вмілі у виконанні і не знали, як ефективно використовувати make.
3. Хоча можна написати короткий і простий Makefile, який ефективно компілює Java, для цього потрібна додаткова обережність, незалежна від платформи.
4. Отже, з'явився апетит до інструменту побудови, незалежно від платформи.
5. Саме в цьому середовищі були створені Мураш і пізніше Мейвен.

Коротше кажучи, хоча максимум, безумовно, може бути використаний для проектів Java, був момент надати можливість зробити його фактично інструментом побудови Java. Цей момент минув.

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

Коротка відповідь: Тому що make це не добре. Навіть на передній панелі С ви бачите багато альтернатив.

Довга відповідь: makeмає кілька недоліків, які роблять її ледь придатною для компіляції на C і зовсім непридатною для компіляції Java. Якщо ви хочете, ви можете змусити його компілювати Java, але очікуйте, що у вас виникнуть проблеми, деякі з яких не мають відповідного рішення чи вирішення. Ось декілька:

Розв’язання залежності

makeпо суті очікує, що файли мають деревоподібну залежність один від одного, в якому один файл є результатом побудови декількох інших. Це вже спрацьовує в C при роботі з файлами заголовків. makeвимагає make-специфічного включення файлу, який повинен бути сформований для представлення залежності файлу С від його заголовкових файлів, тож зміна останнього призведе до того, що попередньо відбудувались. Однак, оскільки сам файл C не відтворений (просто відреставрований), make часто вимагає вказати ціль як .PHONY. На щастя, GCC підтримує генерування цих файлів автоматично.

У Java залежність може бути круговою, і немає інструменту для автоматичного генерування залежностей класів у makeформаті. ant«S Dependзавдання може, замість того, щоб прочитати файл класу безпосередньо, визначити , які класи він імпортує, і видалити файл класу , якщо будь-який з них застаріли. Без цього будь-яка нетривіальна залежність може призвести до того, що ви будете змушені використовувати повторні чисті складання, усуваючи будь-яку перевагу використання інструменту збирання.

Пробіли у назви файлів

Хоча ні Java, ні C не рекомендують використовувати пробіли у назви файлів вихідного коду, makeце може бути проблемою, навіть якщо пробіли знаходяться у шляху файлу. Розглянемо, наприклад, чи існує ваш вихідний код у C:\My Documents\My Code\program\src. Цього було б достатньо, щоб зламати make. Це тому, що makeназви файлів трактуються як рядки. antтрактує стежки як особливі об’єкти.

Сканування файлів для збирання

makeвимагає чітко встановити, які файли потрібно будувати для кожної цілі. antдозволяє вказати папку, яку слід автоматично сканувати для вихідних файлів. Це може здатися незначною зручністю, але врахуйте, що в Java кожен новий клас вимагає нового файлу. Додавання файлів до проекту може швидко стати великим клопотом.

І найбільша проблема make:

make залежить від POSIX

Девіз Java - "компілювати один раз запустити всюди". Але обмежувати компіляцію системами на базі POSIX, в яких підтримка Java насправді є найгіршим, не є наміром.

Правила побудови в - makeце по суті невеликі bashсценарії. Незважаючи на те, що є порт makeдля Windows, щоб він працював належним чином, він повинен бути в комплекті з портом bash, який включає в себе емуляційний шар POSIX для файлової системи.

Це два сорти:

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

2. cygwinщо забезпечує повну емуляцію POSIX. Однак отримані програми, як правило, покладаються на цей рівень емуляції.

З цієї причини для Windows стандартний інструмент збирання навіть не є make, а скоріше MSBuild, що також є інструментом на основі XML, в принципі наближений до ant.

На противагу цьому, antпобудований на Java, може працювати всюди і містить внутрішні інструменти, звані "завданнями", для управління файлами та виконання команд незалежно від платформи. Це досить універсально, що ви можете реально спростити час побудови C-програми в Windows, antніж використання make.

І останній другорядний:

Навіть програми на C не використовують натур

Ви, можливо, спочатку цього не помічаєте, але програми C зазвичай не постачаються з Makefile. Вони поставляються з CMakeLists.txtабо bashскрипт конфігурації, який генерує дійсне Makefile. На відміну від цього, джерело програми Java, побудованої за допомогою ant, поставляється із antпопередньо вбудованим сценарієм. A Makefile- це продукт інших інструментів - саме стільки makeнепридатно бути інструментом збирання самостійно. antє автономним та розглядає все необхідне для процесу збирання Java без будь-яких додаткових вимог чи залежностей.

Коли ви працюєте antна будь-якій платформі, це просто працює (тм). З цим не можна погодитися make. Це неймовірно залежить від платформи та конфігурації.

Якщо я не хтось, припущення, що ніхто не (помилково) використовує make for java, є помилковим.

"Управління проектами за допомогою GNU Make" (доступне під GFDL) містить повну главу, присвячену використанню makeпроектів java.

Оскільки він містить довгий (і, сподіваємось, справедливий) список плюсів і мінусів використання make, а не інших інструментів, які ви можете поглянути там. (див .: http://oreilly.com/catalog/make3/book/ )

Ant - це поліпшення конфігурації XML порівняно з Makefiles, а Maven - це поліпшення інструменту побудови залежності над Ant. У деяких проектах використовуються всі три. Я думаю, що проекти JDK використовували суміш мафік та мурашок.

Однією з головних причин є те, що і Ant, і Maven (і більшість інструментів SCM, CI та IDE, орієнтованих на java) написані на Java розробниками / для розробників Java. Це спрощує інтеграцію у ваше середовище розробки та дозволяє іншим інструментам, таким як сервери IDE та CI, інтегрувати частини бібліотек ant / maven в інфраструктуру збирання / розгортання.

Колись я працював над проектом Java, який використовував gmake. Мій спогад туманний, але IIRC нам важко було працювати зі структурою каталогу пакунків, яку очікує javac. Я також пам’ятаю, що складати файли JAR було клопотом, якщо у вас не було щось тривіальне.

ApacheAnt - це не що інше, як Make. Make - це опис залежностей між файлами та способів побудови файлів. Мураха - це залежність між "завданнями", і це справді більше спосіб склеювання складання сценаріїв разом.

це може допомогти вам AntVsMake

Ент і Мейвен підходять до складання графіка залежності побудови та управління ним з більш «сучасного» погляду ... Але, як каже Оскар, вони створили власні проблеми, намагаючись вирішити старі проблеми з make.

Я ніколи не використовував GNU Make для проектів Java, але використовував jmk . На жаль, він не оновлювався з 2002 року.

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

Сьогодні я просто припускаю, що будь-який розробник Java, з яким я ділюся кодом, встановив Ant.