Неправильная ошибка циклической ссылки
Если вы заботитесь о порядке:
#import operator
import itertools
a = [1,2]
b = ['a','b']
#c = list(reduce(operator.add,zip(a,b))) # slow.
c = list(itertools.chain.from_iterable(zip(a,b))) # better.
print c дает [1, 'a', 2, 'b']
7 ответов
Я, вероятно, проиграю за это. В D2005 у меня был локальный модуль 10k (модуль данных), который полностью перестал компилироваться. Пришлось выделить некоторые наборы данных / код в другой модуль данных. Этот блок 10k был и остается беспорядком. Вам действительно стоит подумать о рефакторинге кода для других модулей. Мой модуль после D2005 / разделение стал еще хуже, но он все еще компилируется в D2007. Итак, мой ответ: а) рефакторинг и б) обновление до D2009.
Кажется очевидным, что это связано с небольшой разницей между компилятором фона и настоящим. Вы можете посмотреть (QualityCentral), что известно по этой теме.
Кроме того, поскольку вы не указали это явно, вам следует удалить ненужные единицы и, если возможно, переместить операторы using вниз до реализации. Возможно, ваш инструмент может помочь с этим.
И просто чтобы убедиться, что вы должны проверить псевдонимы единиц и настройки пути.
Вы пишете, что полная сборка всегда выполняется успешно, но вскоре после с этой ошибкой происходит сбой инкрементной сборки. Предполагая, что вы испытываете это в среде IDE, пытались ли вы использовать компилятор командной строки dcc32 для выполнения инкрементных сборок?
Если вы не укажете ему переключатель «-Q» (который, вероятно, является большинством файлов Makefile или сценариев для командной строки builds do) выводит много информации о том, какие файлы и в каком порядке компилируются. Вы можете либо попробовать выполнить инкрементную сборку после появления ошибки в IDE, либо оставить командную строку открытой рядом с IDE и Alt + Tab для компиляции, полностью пропуская компиляцию в IDE.
Я просто предположим, что у вас есть способ построить с помощью dcc32,
Есть ли у вас другие проекты, в которых используется часть той же кодовой базы? Если вы скомпилируете один из них с другими настройками компилятора или IFDEF, это может изменить некоторые вещи в некоторых DCU, что приведет к циклической зависимости. Полная сборка восстанавливает все DCU, после чего проблема исчезает.
Мы регулярно попадаем в подобные проблемы, и нам никогда не удавалось (или не удавалось достаточно долго) найти точную причину. Похоже, что существует проблема в порядке, который Delphi выбирает для компиляции модулей при нажатии Ctrl-F9, что несовместимо с фактическим порядком зависимости модулей.
- Вы пытались удалить "MyBigFatUnit.dcu" перед нажатием Ctrl- F9?
- Вы пытались изменить порядок объявления ваших модулей в ваших файлах dpr / dpk, чтобы модули отображались в правильном порядке компиляции? (например: если модуль B зависит от модуля A, модуль A должен отображаться первым в dpr / dpk)
Попробуйте Icarus (бесплатно) от Peganza. Если это не говорит вам, в чем проблема, попробуйте их Pascal Analyzer.
У нас тоже есть эта проблема, также с довольно большой кодовой базой.
В настоящее время мы используем D2009, но эта проблема была у всех предыдущих версии Delphi.
Чаще всего это происходит сразу после выполнения обновления из системы управления версиями, поэтому я подозреваю, что в процессе сборки Delphi есть некоторая проблема с отметкой времени.
В нашем случае, если Ctrl-F9 дает сбой и сообщает циркуляр ссылка, второй Ctrl-F9, как правило, будет работать