?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Next Entry
build(?) tool.
nyaload
_winnie
Помимо того что maven при стирании *.java не стирает *.class, он ещё и не пересобирает зависимый *.class если в *.class другого модуля изменилась сигнатура вызываемого метода. Эм, получается что надёжная не-clean-сборка вообще в принципе невозможна.


  • 1
(Deleted comment)
Ага, у меня такое было, но мне повезло, я как-то сразу понял что происходит (у меня был открыт filemon, незаменимая тулза против волшебства). install у меня не делается, jar-файлы и прочие сгенерированные файлы распространяются через svn. А тот install был случайным.

(Deleted comment)
<ирония>И код надо хранить не под контролем версий, а в виде файлов на сетевом диске, потому что система контроля версий может глючить, как и сборка. Инкрементальное скачивание изменившихся файлов - это сложные алгоритмы, могут глючить. Использовать надо только голую файловую систему на флешках! </ирония>.

Неответственные билды (которые перед коммитом по пять раз в день) тоже хочется что бы были надёжными.

Даже локальные билды которые по 100 раз в день желательно должны быть надёжными. Иначе можно ловить несуществующий баг или не замечать существующий.


Edited at 2010-12-09 10:26 pm (UTC)

как я понял из вашего контекста, она все .class файлы тупо пихает в .jar, не сверяясь со списком файлов в проекте?

ага. удалил java файл, а class остался, потом вся директория с **/*.class упаковалась в jar. Какие-то вообще студенческие баги.


Edited at 2010-12-09 10:16 pm (UTC)

А расскажи мне, ради фана, какой билд тул такое умеет?

1. Стирать объектный файл из output dir, когда соответствующий сырец сдох. Без clean.
2. Пересобирать объектный файл, если изменился не сырец, а его бинарная (не по #include) зависимость.

Вот что-то похожее, про пункт '2': http://ant.apache.org/manual/Tasks/depend.html
С подробным описанием, что может, и что не может.

Сам ещё не проверил. Про пункт "1" явно не написано. Но это можно сделать даже тупым шелл-скриптом (хм, правда тупой не учтёт удалённые Inner-классы).

make в IDEA тоже корректно пересобрал зависимый файл, но я не проверял, сделал он это инкрементально или через пересборку всего.

Все уважающие себя билд-системы для C++ пересобирают .cpp если .h-файлы изменились.

Edited at 2010-12-12 09:25 pm (UTC)

> Про пункт "1" явно не написано. Но это можно сделать даже тупым шелл-скриптом (хм, правда тупой не учтёт удалённые Inner-классы).
Во-во. Никто не умеет :)

> make в IDEA тоже корректно пересобрал зависимый файл, но я не проверял, сделал он это инкрементально или через пересборку всего.
Он инкрементальный, детект зависимостей как бы есть, но крайне глючен = ему нельзя доверять, надо делать rebuild.

> Все уважающие себя билд-системы для C++ пересобирают .cpp если .h-файлы изменились.
Я специально просил исключить #include из обсуждения.
Объясняю почему.
Хедеры, с точки зрения компилятора, неотрывная часть соответствующего сырца.
Они инлайнятся в него, чёрт побери.
Если бы в яве были инклюды и макросы, всё работало бы абсолютно аналогичным способом.
Но их нет (и заодно многочасовых билдов тоже).

Проверил ant depend. Без флажка closure для рекурсивного распространения зависимости не детектит зависимость от базового класса при цепочке наследования или при long.chain.of.fields.Method(). А с closure пересобирает сликшом много зависимых классов (это может оказаться весь проект). Что чуть хуже чем С++, где такой кошмар для *.h-файлов, но не для правок внутри *.c-файла.

Есть ещё некий jikes, замена javac, который говорит что может хорошо детектить зависимости, но не знаю можно ли использовать его на практике для большого проекта.




Edited at 2010-12-12 09:52 pm (UTC)

Про jikes я слышал жалобы на бажность в виде некомпилируемого нормального кода и кривого получаемого байткода.

Подведём итогом, что мавен такой же как и остальные билд тулы - не лучше и не хуже :) (в части запуска компилятора с нужными параметрами)

http://johlrogge.wordpress.com/2010/12/14/why-i-dont-like-maven/

  • 1