Опция компилятор Rebuild не разрешает использовать .pcu файлы (то есть прекомпилированные версии модулей). Но я бы не был так уверен, что кнопка “Перекомпилировать всё” ставит именно эту опцию.
Ну, можете сами проверить по датам изменения .pcu файлов. И не забудьте отдельно проверить случай когда компилируете программу, а модуль, подключённый к ней не открыт в редакторе. А то редактор любит обновлять время изменения .pas файлов, открытых в нём, даже если ничего в них не поменялось, а это делает .pcu файлы устаревшими (и тогда компилятор их игнорирует).
“Unit1.pas” закрыт, “Компилировать”, время изменения .pcu файла и доступа к .pcu файлу не изменилось.
“Unit1.pas” закрыт, “Перекомпилировать все”, время изменения .pcu файла изменилось.
“Unit1.pas” открыт, фокус на “Тест компилировать перекомпилировать все.pas”, “Компилировать”, время изменения .pcu файла и доступа к .pcu файлу не изменилось.
“Unit1.pas” открыт, фокус на “Тест компилировать перекомпилировать все.pas”, “Перекомпилировать все”, время изменения .pcu файла изменилось.
“Unit1.pas” открыт, фокус на “Unit1.pas”, “Компилировать”, время изменения .pcu файла и доступа к .pcu файлу не изменилось.
“Unit1.pas” открыт, фокус на “Unit1.pas”, “Перекомпилировать все”, время изменения .pcu файла и файла “Unit1.pas” изменилось.
Выходит, предположения опровергнуты. Вопрос остаётся открытым. В Интернете есть исходный код PascalABC.NET, так я наверняка пропустил часть с объяснением функций кнопок графического интерфейса IDE, или всё-таки этого там нет?
Я внимательно проверил:
Кнопка “Компилировать всё” таки вызывает обычную компиляцию, но с CompilerOptions.Rebuild = true.
И Rebuild таки только вырубает использование .pcu файлов.
Это как вообще? Если компилировать файл модуля - его .pcu точно меняется. По крайней мере если это не проект, за них не ручаюсь. Вы ничего не перепутали?
Насчёт описания результатов тестов - вы бы хоть - поставили перед каждым результатом, чтоб всё превратилось в не_нумернованный список. Когда нормально отделено - на много проще читать. А вообще Markdown позволяет делать полноценные таблицы:
Изм. Даты изм. .pcu
U закр.
U откр.
U откр. + фокус
Компилировать
Нет
Нет
Нет???
Компилировать всё
Да
Да
Да +.pas
Возможно я слабо выразился, но эти результаты подтверждают именно то, что имел в виду я:
Rebuild режим заставляет компилятор игнорировать существующий файл прекомпилированного модуля. То есть компилятору приходится ещё раз прочитать и откомпилировать .pas файл модуля, вместо того чтоб брать уже готовое.
На создание нового .pcu файла - это никак не влияет. Если модуль был откомпилирован - его сохранит как .pcu файл, не зависимо от настроек. Настройки могут управлять только папкой, куда попадёт .pcu файл.
Я как раз проверял, создав проект. Сейчас я проверил без проекта. Открыл MyUnit.pas и WritelnString.pas. Если нажимать “Компилировать” или “Перекомпилировать все”, фокусируясь на одном .pas, это никак не затрагивает остальные открытые .pas. Независимо от того, скомпилирован уже .pas в фокусе или нет, при нажатии “Компилировать” или “Перекомпилировать все” изменяется время изменения .pas в фокусе и его скомпилированных файлов, либо изменяется время изменения .pas в фокусе и создаются новые скомпилированные файлы соответственно.
Будем считать это решением вопроса. Но зачем вообще может понадобиться “игнорировать существующий файл прекомпилированного модуля”?
Не представляю зачем его добавили, но вообще в компиляторе всё ещё есть пара багов, при которых генерируются сломанные .pcu . Ну, я обычно переключаюсь на вкладку модуля и компилирую его отдельно, это тоже всё исправляет. И получая эти баги я в модулях несколько сотен строк, так что рядового пользователя это редко заденет.
Если открыть файл программы, к которой подключён модуль - при компиляции программы с опцией Rebuild всё равно должен обновится .pcu . А в проектах, видимо, не важно какая вкладка открыта - IDE не даёт компилировать ничего кроме всего проекта.
То есть, чтобы избежать возможные баги при компиляции .pcu, нужно либо переключиться на каждую вкладку модуля и нажать “Компилировать”, либо переключиться на главный файл программы и нажать “Компилировать все”? В каких случаях это нужно делать: если модули в проекте, если проект не создан?
Чтобы избежать возможные баги при компиляции .pcu и удостовериться в совместимости после обновления IDE, нужно либо переключиться на каждую вкладку модуля и нажать “Компилировать”, либо переключиться на главный файл программы и нажать “Компилировать все”? В каких случаях это нужно делать: если модули в проекте, если проект не создан?
Учтите еще, что программа может иметь несколько уровней вложенности подключаемых модулей или библиотек. Напр., у вас в программе используется pcu-модуль, который в свою очередь зависит от другого модуля (или библиотеки). Если последний изменился, то вашу главную программу нужно пересобрать (т.е. выполнить rebuild), а не просто перекомпилировать (recompile), для того чтобы в pcu 1-го уровня был уже использован код новой версии модуля 2-го уровня, а к основной программе не подключился старый прекомпилированный файл pcu 1-го уровня. Это если все эти файлы не объединены в проект, конечно – там все зависимости должны учитываться и пересобираться автоматом, но я это не проверял.
Это вы много додумываете там, где я не хотел вдаваться в детали. Я имел в виду что время от времени получаю пару плавающих багов, когда тыкнул на вкладку программы “ПКМ >> Сделать активной”, переключился на вкладку модуля и там нажал кнопку запустить.
В сложных модулях это иногда создаёт неправильный .pcu, при компиляции с которым выскакивает внутренняя ошибка. Вот если откомпилировать с Rebuild опцией, или отдельного откомпилировать модуль, чья вкладка была активной - всё исправляется. Но пока я не могу найти код, в котором это будет стабильно.
Для этого в заголовке .pcu хранится его версия. .pcu с неправильной версией игнорируется не зависимо от того, как компилировать. Все остальные обыденные случаи не_правильности .pcu тоже предусматриваются.
И если какой то обыденный случай будет не предусмотрен - это баг, а не “фича” которую надо покрывать дополнительными фичами вроде “Компилировать всё”.
Зависимости модулей обрабатываются абсолютно одинаково в проектах и в просто программах. Файл проекта даёт компилятору информацию вроде списка подключённых .dll, но никакой информации о модулях.
Чтоб сделать активным файл основной программы, тогда без проектов можно запускать определённую программу, не переключая фокус с вкладки модуля на вкладку собственно программы.
Как выглядит и когда происходит (ври выполнении из оболочки, при компиляции, в откомпилированной программе) переход к месту ошибки в стандартных модулях (связано с опцией SkipStakTraceItemIfSourceFileInSystemDirectory)?
Какие проблемы могут возникнуть, если включена/отключена опция “Ускорять запуск из-под оболочки” (UseDllForSystemModules, UseDllForSystemUnits)?
При выполнении. Стек выполнения существует только при выполнении программы.
Напишите программу с raise и запустите. Так же красным может подсвечивать строчку в модулях. И если разрешить эту опцию - и в стандартных тоже. А если запретить - подсвечивать будет строчку, которая вызвала подпрограмму из стандартного модуля, где выпала ошибка.
Эта опция должна была разрешать использовать содержимое заранее созданной .dll, содержащей всё то же что все модули. Это значит что программа не будет работать без этой .dll, но в случае больших модулей как OpenGL - при каждом запуске программы не надо ждать пока компилятор пройдётся по всему модулю.
Но… В итоге это обрубок от фичи: опция есть, а кода для использования .dll в компиляторе нет.
Не при запуске, а при компиляции программы. И по всему модулю компилятор не проходится. Из pcu считываются только используемые сущности по мере необходимости.
Это не обрубок, а фича только для системных модулей и только по F9. Компиляция с PABCRtl.dll бессмысленна, потому что exe-шник без него не будет работать
Да, разумеется, но при компиляции это не проблема. Проблема в том что компиляция происходит при каждом запуске, даже если поменять 1 строчку. То есть после мелкого изменения надо ждать чтоб запустить проверить, как оно выглядит.
Сама опция тоже называется “ускорять запуск из под оболочки”. Потому что к компиляции это нет смысла применять.
Я только про стандартные и говорю. Для них эта фича и не работает.
Я относительно недавно закапывался в код компилятора, смотрел. И вот что из этого запомнил - так это то, что в компиляторе есть опция в CompilerOptions (или как оно там), но она никак далее не обрабатывается.
Конечно, эта фича имеет смысл только на время дебага. Хотя в теории PABCRtl.dll можно таскать с .exe и всё будет работать, хоть это и глупо.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021