Есть ли общее правило, когда вы должны использовать «make clean» вместо «make»?

11

Я пишу многофайловую программу прямо сейчас, и, очевидно, запускаю только «make» (как можно было бы интуитивно подумать, что это нужно сделать в большинстве ситуаций), по какой-то причине моя программа перестала работать. Я думаю, что могу предоставить более подробную информацию о проблеме, но важно то, что она работает при использовании 'make clean'. Так что мне было интересно, знает ли кто-нибудь общее эмпирическое правило для запуска «make clean» вместо «make»

c++ builds make

— Темный тамплиер
источник

17

Вы запускаете make clean в двух ситуациях - когда вы хотите упаковать исходный код (и, следовательно, вам не нужны / не нужны встроенные объекты) ИЛИ когда у вас есть основания полагать, что встроенные объекты плохие.

В вашем случае вы используете 'make clean', чтобы исправить проблему, которая, вероятно, является результатом глючного Makefile. Что-то там не перекомпилируется, когда это необходимо, и это приводит к тому, что выходной двоичный файл будет плохим.

Есть много причин, которые могут произойти, в зависимости от сложности вашего проекта и от того, как вы использовали make, но суть его такова: вам нужно потратить некоторое время на отладку вашего Makefile.

— Майкл Кон
источник

6

Вы забываете «некоторые изменения в среде сборки», такие как обновленный компилятор, новые версии библиотек и т. Д., Всегда хорошая идея «очистить» в этих случаях просто для того, чтобы убедиться, что все модули поют из одного и того же листа песен!

— Джеймс Андерсон

2

@JamesAnderson Можно утверждать, что это просто примеры глючных Make-файлов.

— Кристоф Провост

4

@KristofProvost: Я не уверен, что классифицировал бы «Новый ABI» (возможно, путем введения новой версии компилятора) как «глючный Makefile». Это вполне выходит за рамки того, на что я бы рассчитывал.

— Ватин

1

Это правда, но возможно (и даже не так сложно) добавить компилятор в make-файлы в качестве предварительного условия. Этого достаточно, чтобы поймать проблему. В общем, это не очень большая проблема, и в любом случае это очень редко. Я сделал это, потому что я использовал (и написал) make-файлы, которые учитывают флаги компилятора и тому подобное. Это также довольно редко встречается в make-файлах, но очень полезно (больше, чем проверка компилятора;)). Мои ожидания от хороших, хорошо написанных make-файлов довольно высоки. Мои ожидания от среднего make-файла довольно ниже ...

— Кристоф Провост

8

Я согласен с ответом Майкла Кохна в целом. Я бы добавил, что вам нужно прочитать документацию по установке, чтобы узнать, что на самом деле делает «make clean». Вам могут понадобиться разные уровни очистки, такие как «make realclean» и «make distclean». Есть неофициальные соглашения для них, но ничто не высечено в камне.

— Билл Рупперт
источник

2

+1: «вам нужно прочитать документацию по установке, чтобы узнать, что на самом деле делает« make clean »». Там нет "общего правила". Вы должны на самом деле читать документы.

— С.Лотт

5

Я понимаю, что это ваш проект, так что это ваш makefile. Моя цель - make всегда создавать правильную сборку, если это возможно. Если make cleanнеобходимо оправиться от какого-либо состояния, то, на мой взгляд, makefileэто неправильно, и должно быть исправлено. Если ваши зависимости были рассчитаны правильно, то простой makeдолжен перекомпилировать все, что нужно перекомпилировать.

— Кевин Клайн
источник

2

Согласен. В наши дни это больше не проблема почти бесконечного дискового пространства, но я достаточно взрослый, чтобы помнить, когда make clean и make realclean использовались в основном для экономии места на диске после создания связанного исполняемого файла. Создание GCC, Apache, Perl и т. Д. Оставило много вещей, лежащих вокруг.

— Билл Рупперт

1

Я запускал "make clean" перед ночной сборкой. В этом случае дополнительное время, необходимое для полной сборки, вероятно, не будет иметь большого значения, но дополнительная безопасность, которую вы получите, убедившись, что все в правильной версии, вероятно, того стоит.

— Захари К
источник

Это будет зависеть от размера вашего проекта. Там, где я работаю, инкрементная сборка займет 2-4 часа, а изменения с других сайтов будут перенесены в одночасье. Чистая сборка может занять от 7 до 9 часов. Помимо этого у нас иногда было 2 или 3 ветви, которые мы хотели бы построить. Даже на быстрых машинах очень большие базы кода должны обрабатываться совсем иначе, чем меньшие.

— TafT