Зачем в таком случае нужна сейчас опция /rebuild в pabcnetc.exe и “Перекомпилировать все” в IDE, если нельзя с их помощью полноценно скомпилировать PABCRtl.dll или аналогичную автономную библиотеку? В каких еще ситуациях они реально могут быть полезны (кроме плавающего бага с порчей сборок)?
Зачем вообще нужна pabcnetc.exe в дистрибутивах, если её функционал в таком урезанном виде почти полностью покрывается pabcnetcclear.exe? Ну, кроме работы по маске (только внутри и крайне ограниченно) – что элементарно замещается однострочным батником с FORFILES /m *.pas [/s] /p %1 /c "cmd /c pabcnetcclear @path" – и сомнительного по практичности полуцветного недоделанного интерактивного режима с ручным(!) переключением языков (только внутри!).
Если уж совсем откровенно, то качество и понятность лога, обработка ошибок и аргументов командной строки в нем вообще сейчас ужасны: шаг вправо-влево – ошибка или вообще краш! И весь дальнейший текст в консоли становится розовым…
Общепринятый в Windows параметр запроса подсказки “command /?” мгновенно приводит к краху(!) с попыткой компилировать файл “?”.
Порядок следования параметров в строке прибит гвоздями и при этом не совпадает с оными у его “младшего брата” pabcnetcclear (причем не только сам порядок, но и синтаксис аналогичных опций), что регулярно приводит к путанице, ошибкам и лишней потере времени, особенно при удаленной отладке.
Не имеет опции рекурсивной компиляции файлов, начиная с указанной папки
Работа с масками файлов и путями (абсолютными или относительными – неважно) в командной строке невозможна вообще, только в интерактивном режиме и то ограниченно и не везде. Если указать несуществующую директорию в командной строке – сразу розовый крэш!
В интерактивном режиме с опцией Rebuild=1 почему-то может работать только с файлами в текущей папке, но при Rebuild=0 можно уже писать что-нибудь вроде dir1\dir2\*.pas, но все равно нельзя ..\dir1\dir2\*.pas.
При этом не отфильтровывает исходники автоматически по маске *.pas: может по ошибке пытаться компилировать что угодно и тут же крашнуться, если просто ошибиться в имени файла или маски.
Есть возможность интерактивно менять рабочую директорию (cd), но нет возможности посмотреть в ней список файлов и папок (dir или ls) – работай вслепую!
Статистика по строкам и размеру скомпилированного кода работает вообще не пойми как. Выводит что-то вроде Total: 3 files (123kb,2456lines). Time: 13914,2134ms вместо более читабельного Compiled: 3 files (123 KB, 2 456 lines). Took: 0m 13,9s.
Подробный вывод по умолчанию включен при задании опции /rebuild в командной строке, но почему-то выключен по умолчанию в интерактивном режиме (нужно вручную набирать ShowAllMessages=1).
Автозавершения внутренних команд (их всего 10 пока) нет, приходится все набирать полностью.
Если указать команду-флаг без =0 или =1, не понимает, что достаточно инвертировать значение, вместо этого показывает статистику пустой компиляции, как при неправильно набранном имени файла.
В подсказке указано, что по умолчанию режим Debug выключен [0], а на самом деле он включен и создает .pdb (в командном режиме он вообще неотключаем!).
Команды OutType, Reset, ResetOnCompile нигде не описаны и совершенно не ясно в каких случаях они могут быть полезны.
“Шапка” содержит массу служебной и абсолютно бесполезной для пользователя информации. Но при этом подсказка по опциям неполная – напр., вообще не отмечена возможность задания некоторых параметров сразу через командную строку.
Использование цвета в консоли в простейшем интерфейсе – бессмысленное излишество, причем только создающее проблемы с перенаправлением ввода/вывода.
Выйти из интерактивного режима можно только по Ctrl-C, но об этом нигде не упоминается – догадайся сам.
И это еще не полный список… Серьезно работать с этим мучительно. А pabcnetcclear, хоть и функционально куцый, но хотя бы гораздо менее проблемный. Надо хотя бы параметры командной строки у них сделать синтаксически совместимыми и желательно не зависимыми от порядка следования (может ‘–’ или ‘-’ вместо ‘/’ в кач-ве начала опции?).
Ну вот, выговорился – полегчало! Никого не хотел обидеть, просто накипело…
PABCRtl.dll - он не для непосредственного использования.
/rebuild перекомпилирует свои модули - я уже об этом говорил. С лёгкой руки не разобравшегося @Sun_Serega все стали говорить, что он “бесполезен”
Про “плавающий баг с порчей сборок” я первый раз слышу. Опишите его и напишите Issue. Пока для меня такого бага нет.
По поводу консольных компиляторов - да, хорошо бы чтобы кто-то взялся переписать, устранив какие-то ошибки и неточности и добавив параметры. Но нужно, чтобы старые параметры со старой командной строкой работали - у нас системы олимпиад на это завязаны
pabcnetc.exe - это к тому же еще и интерактивный консольный компилятор. Зачем он нужен лично Вам - я конечно не представляю. Он очень древний - да.
pabcnetcclear.exe - да он писался сильно позже. Еще раз повторюсь - прекрасная идея если кто-то бы потратил силы его дописать и исправить мелкие ошибки и неточности. На мой взгляд, это очень полезное вкладывание сил.
Порча сборок это отдельная проблема. Компилятор привык сувать минимум в .exe, чтоб не перенагружать его. С .dll так нельзя, но разработчики хотели сделать более продуманное решение, чтоб можно выло выбирать - какие модули резать, а какие нет.
Ну как первый раз, если у нас с вами был спор на форуме “надо ли в пользовательские .dll сувать всё содержимое модулей”, который кончился issue #2018 о которой все забыли.
Я всегда думал, что считает только строки которые перекомпилировало. То есть если весь модуль из .pcu взяло - его строки не считает.
Ну, это бред, пользователю не нужны кишки работы с .pcu файлами. Если давать кол-во строк - то целиком.
Я помнил что ещё в 2019 разбирался, потому что с модулем где эта опция была бы реально полезна (OpenGL) - эффекта не было. Тогда я не нашёл в компиляторе части подгружающей rtl в сам компилятор (иначе как из него методы брать) и заметил что этой библиотеки нет в дистрибутивах. Вы подтвердили, поэтому я дальше и не копался. Это что то типа шутки было?
Я читаю то, что Вы тут написали, и не понимаю, о чём это. Ссылка идёт на какие-то старые посты Волобуева, который Соколиный глаз, и там не о том.
Вообще, добавьте в название Issue для import что то более информативное: Чтобы в dll входило всё содержимое модулей - как-то так
А всё же - зачем такая возможность? Казалось бы - пишете себе dll - всё что вы хотите в ней чтобы было - реализуете, вызываете сервисные функции из модулей. Понятно.
Но брать уже готовый модуль и пытаться превращать его в dll нельзя. На C# такого и в голову не придёт - там это нельзя в принципе. Так зачем это здесь?
Это в центре окна. А когда форум открывает сообщение по ссылке - это сообщение оказывается в самом верху окна. Ну, может так будет проще заметить, на что я ссылался:
Вот и я о том же! Это бред, пытаться публично зашить в .dll содержимое модуля. Но сейчас - все классы и глобальные переменные и подпрограммы получают модификатор доступа public.
Таким образом, к примеру, если кто то напишет свою библиотеку вроде WPF и использует в ней модуль OpenGL - каждый пользователь этой библиотеки будет видеть не только то что им надо, но и кишки, которые от рядового пользователя библиотеки всегда должны быть скрыты.
И если б хотя бы это был полный набор кишок - так нет, в библиотеку попадает только огрызок, только то - что было использовано в высокоуровневых методах библиотеки.
Я уже не идеально помню, но:
Я столкнулся с этим в 1 своём проекте (который я всё ещё хочу закончить, когда то), где распространялась .dll и ожидалось что она будет подключаться к другим .Net языкам. Но в неё начали попадать кишки моих методов для создания окон и т.п. Поэтому изначально я был за то, чтоб давать содержимому модулей модификатор internal.
Но кто то (вроде @ibond) сказал что попадание содержимого модулей в .dll как есть - зачем то всё же нужно. И в итоге решили что добавить новый синтаксис с uses будет лучшим решением.
А что мешает его использовать (когда он помещен в GAC) и вне IDE, напр., для более быстрого запуска каких-нибудь маленьких самописных консольных утилит? Такие “зависимые” бинарники можно сейчас стандартно получать через IDE, было бы неплохо, если бы и консольные компиляторы могли такое генерить опционально.
Мне он сейчас нужен только для сборки полноценного PABCRtl – я бы про него забыл как страшный сон вообще. Больно уж я с ним намучился, пока не разобрался в его “особенностях”. А пока экспериментировал с ним, ужаснулся: нет, не его древности, а его общей глючности, непродуманности, странностям и недоделкам.
Скажите, а кто и где реально использует этот интерактивный режим? Это просто была чья-то курсовая или действительно реальный юзкейс. Просто любопытно.
Лезть и исправлять такое кому-то со стороны – дело крайне гиблое и неблагодарное, проще уж новую командную оболочку написать, да только кому оно нужно? Гораздо полезнее и разумнее будет доработать pabcnetcclear /rebuild.
От этого будет уже не теоретический, а весьма практический профит для всего проекта – я имею в виду регулярные, публичные, повторяемые, верифицированные и автоматизированные сборки и тесты, со строгим сопоставлением номера билда и соответствующим ему коммитом, чего сейчас весьма не хватает.
Да, я совсем запарился сегодня – конечно, я имел в виду PABCRtl. Просто я смотрел в открытый код RebuildStandartModules.pas, а думал при этом про Rtl Смотрю, там есть OpenCL/OpenCLABC и OpenGL/OpenGLABC, но нет их *Base вариантов.
Глянул сейчас в код PABCRtl – там вообще нет ни OpenCL, ни OpenGL. Видимо, они слишком большие и редко используемые, поэтому их не включили.
Ну, там вообще много чего нет из того, что поставляется в комплекте и это разумно с точки зрения главной цели – ускорения запуска типовых учебных программ. Хотя, можно ведь самому собрать и зарегать в GAC свой кастомный PABCRtl c нардами и домино
Зачем в _GenerateAllSetups.bat, _RebuildReleaseAndBuildUnits.bat и _RebuildReleaseAndRunTests.bat повторно пересобираются стандартные модули сразу после сборки, подписания и регистрации в GAC свежей PABCRtl.dll?
Нужен ли ICSharpCode.NRefactory.dll в консольном дистре (zip)?
Я уже не помню обсуждение, но я согласен - кишки надо скрывать модификатором internal. Надо аккуратно на это посмотреть и написать Issue - какие именно кишки
Ну, никто не проектировал PABCRTL.dll. Причина банально проста. У нас при компиляции каждой программы весь (!) PABCSystem разворачивается в виде семантического дерева в памяти. Это долго - особенно на медленных ноутбуках в дисплейных классах. Для наших простых задачек для школьников с исполнителями Робот и Чертежник при каждой компиляции приходилось ждать по 3-5 секунд. PABCRTL решила эту проблему.
Собственно , это был первый консольный компилятор, и он писался 15 лет назад. С тех пор его практически никто не переделывал. Прагматически он использовался в оболочке для компиляции и запуска программ, интерактивный режим был введён скорее заодно, особой роли он никогда не играл.
Повторюсь, консольный компилятор надо бы полностью переписать.
Перед этим разумеется сформулировать чёткую спецификацию параметров командной строки.
Если начнете делать, имейте пожалуйста в виду, что порядок старых параметров трогать не надо - иначе в олимпиадных системах при смене версии возникнет коллапс.
От чего восстановиться? Там же в 2-х файлах из 3-х все С# проекты вообще собираются только под .NET 4.7.1 (PascalABCNET.sln) и только в одном – в 2-х вариантах (PascalABCNET.sln + PascalABCNET_40.sln).
Но общее у них то, что сразу после сборки Паскаля под .NET 4.7.1 сначала компилируются все его стандартные модули, потом PABCRtl.dll (который в режиме /rebuild опять же принудительно перекомпилирует значительную часть этих же модулей), а конце зачем-то еще раз перекомпилируются все стандартные модули Паскаля. В чем тут смысл?
По-моему, 1-ая компиляция стандартных модулей (до PABCRtl.dll) там абсолютно лишняя, а 2-ая компиляция (после создания PABCRtl.dll, скомпилированного с опцией /rebuild) вполне может обойтись уже обычным режимом (без /rebuild) – это сэкономит время.
Вы, наверное, путаете с тем, что только в _GenerateAllSetups.bat в самом конце повторно пересобирается весь PascalABCNET.sln после промежуточного этапа работы с PascalABCNET_40.sln, хотя это и не лучшее решение – лучше бы сделать копию папки \bin после работы с PascalABCNET.sln, а в конце её восстановить на место текущего \bin (с файлами от компиляции PascalABCNET_40.sln).
Кстати, пересборка стандартных модулей и PABCRtl.dll разными дистрами Паскаля (под .NET 4.7.1 и NET 4.0), как я понимаю, не требуется – генерируемый ими MSIL код должен быть абсолютно идентичен. Или я не прав?
Посмотрел, нашел-таки зависимость Compiler.cs всего в 2 местах от ICSharpCode.NRefactory.dll, но там он вроде был нужен только для компиляции VB.NET кода в функции CompileVB() – это еще поддерживается вообще?
Не знаю, о какой именно ошибке сборки для 4.0 вы говорите, но я недавно тут обнаружил одну проблему конфигурации сборки , на которую вы, похоже, не обратили внимания из моего длинного поста выше, поэтому я повторю свой текст:
Из-за ошибки в настройке проектов CodeTemplatesPlugin.csproj и CodeTemplatesPlugin_40.csproj откомпилированная CodeTemplatesPlugin.dll сейчас не попадает в папку \bin. Разработчики этого не замечают скорее всего потому, что у них локально в \bin сохранилась еще “старая” копия. По этой же причине, я думаю, в последнее время в XP-версии регулярно ломается функционал шаблонов кода, т.к. в XP-дистрибутив все время попадает эта “старая” сборка, сконфигурированная для платформы .NET 4.7.1, а не 4.0.
Никого не хотел обидеть, просто накипело…
Смотрю, там есть OpenCL/OpenCLABC и OpenGL/OpenGLABC, но нет их *Base вариантов.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021