Мы используем инструменты сборки, потому что они представляют собой практичный способ компиляции кода и создания исполняемых файлов, например, deployables и т. Д. c.
. Учтите, что у вас есть большое Java приложение, состоящее из тысяч отдельных исходных файлов, разделенных на несколько пакетов. Предположим, что он имеет ряд зависимостей JAR-файлов, некоторые из них для разработанных вами библиотек, а другие - для внешних библиотек, которые можно загружать из стандартных мест.
Вы можете потратить часы на ручную загрузку внешних файлов JAR и положить их в нужном месте. Затем вы можете вручную запустить javac для каждого из исходных файлов и jar несколько раз. Каждый раз в правильном каталоге с правильными аргументами командной строки ... и в правильном порядке.
И каждый раз, когда вы меняете исходный код ... повторяйте соответствующие части вышеописанного процесса.
И убедитесь, что вы не допустите ошибки, которая приведет к потере времени на поиск ошибок тестирования, ошибок времени выполнения и т. Д. c, вызванных неправильной сборкой.
Или ... Вы можете использовать инструмент сборки, который позаботится обо всем этом. И делает это каждый раз правильно.
В итоге, мы используем инструменты сборки:
- Они меньше работают, чем делают это вручную
- Они более точные
- Результаты более воспроизводимы.
Я хочу знать, почему компилятор не может этого сделать?
Потому что компиляторы не предназначены для выполнения всего процесса сборки. Точно так же, как ваша печь не предназначена для приготовления блюд из трех блюд и подачи их на обеденный стол.
Компилятор (как правило) предназначен для компиляции отдельных файлов исходного кода. В построении есть нечто большее, чем это.