=?iso-8859-1?q?=5Bkde-russian=5D_=F0=D2=CF_=22=CE=C5=D2=C1=C2=CF=D4=D5=22?= =?iso-8859-1?q?_KDE_=C9=DA_CVS?=

[Nikita V. Youshchenko]

Прочитал про проблемы со сборкой CVS и Вспомнил. Вдруг кому интересно ...

Когда (несколько месяцев назад) у меня висел сервис, пересобирающий KDE из 
CVS каждую ночь, я сталкивался с такой ситуацией. Происходила следующая 
последовательность событий.

- делался cvs update,
- cvs менялся, с соответствующей установкой времени модификаций файлов,
- происходила сборка,
- (на следующую ночь) происходил новый cvs update
В результате время создания объектника оказывалось больше, чем время 
модификации файла (CVS при обновлении устанавливает в качестве времени 
модификации локального файла время соответствующего коммита), и при 
следующей сборке объектник не пересобирался. В результате, естественно, 
сегфолты.

Лечится это либо чистой сборкой каждый раз (если ну очень быстрая машина), 
либо скриптом, обнаруживающим эту ситуацию и удаляющим устаревшие 
объектники. У меня висела такая штука:

# Workaround commit-between-update-and-compile problem
egrep "^P |^U " LOGS/update | awk '{print($2)}' | while read x; do
  dn=`dirname $x`
  bn=`basename $x`
  mbn=`echo $bn | sed 's/\(.*\)\..*/\1/'`
  if [ "$bn" != "$mbn" ]; then rm -f $dn/{,.libs/}$mbn.{o,lo}; fi
done

где в LOGS/update была выдача cvs update. Но это не совсем правильно, т.к. 
не отлавливает ситуацию, когде модифицирован хэдер, но не cpp-шник.