|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
24.05.2022, 22:38 | #1 |
Новичок
Джуниор
Регистрация: 28.12.2011
Сообщений: 2
|
Как скомпилировать библиотечный модуль (.pas) не помещая его в Library path ?
Ситуация: вот есть у меня модуль, содержащий пачку полезных функций, для использования в разных проектах. Не компонентов, просто функций.
Ну, допустим, с именем MyUtils.pas Кладу его в папку, включенную в Browsing path. Создаю проект, указываю MyUtils в uses. Упс, это имя подчеркнуто красным, а в окне Structure выводится сообщение: "F2063 Could not compile used unit 'MyUtils' " Ну и при попытке компиляции также - " [dcc32 Fatal Error] F2613 Unit 'MyUtils' not found." При этом по Ctrl-click исходник модуля открывается, и именно из указанной папки (что проверяется через пункт "Show in explorer" контекстного меню вкладки). Если папку с .pas включить в Library path - компилируется. Раньше я всегда так и делал, и не парился. Но нынче я стал более осознанно подходить к порядку в папках, и в процессе изучения вопроса неоднократно встречал мнение, что так делать неправильно, в Library path следует указывать папки со скомпилированными модулями и библиотеками (dcu, bpl), а не с их исходниками. Например тут: https://www.cyberforum.ru/blogs/190319/blog5708.html https://stackoverflow.com/questions/...es-of-packages И как, не нарушая этого принципа, таки скомпилировать .pas, чтобы получить .dcu для помещения в папку, указанную в Library path? Пришла в голову только одна мысль - сделать аналогично библиотекам компонентов, то есть создать в той же папке где лежит этот .pas "служебный" проект, куда и включить модуль явно. Проверил - работает (ожидаемо). Но этот метод кажется мне несколько громоздким, хотя и логичным. И у меня не получилось нагуглить описания такого метода в течение пары часов гуглинга. Я бы предпочел, чтобы компиляция такого модуля происходила при компиляции первого проекта, который его использует в uses, а уже потом использовался получившийся dcu. Но видимо, это работает только для модулей, непосредственно включенных в проект. Вообще, таки логично, что библиотеку следует компилировать независимо от рабочих проектов. Но каковы же best practices в этом вопросе? |
24.05.2022, 23:06 | #2 |
Участник клуба
Регистрация: 17.04.2022
Сообщений: 1,833
|
А разве после компиляции проекта у вас не появляется файл MyUnit.dcu (MyUnit.bpl). Закидывайте его в LibraryPath и все.
А MyUnit.pas кидайте в SourcePath чтобы редактор не ругался на отсутствие исходного текста. ADD: Если вы надеетесь редактировать MyUnit.pas дальше, то не выйдет. Это все настроено для статических текстов. *.dcu - откомпилированы и лежат в LibraryPath не предполагая внесение изменений в соответствующий *.pas. *.pas нужен только для редактора исходных текстов. В стандартные модули изменения не вносятся (обычно). Последний раз редактировалось macomics; 24.05.2022 в 23:29. |
01.06.2022, 18:16 | #3 |
Новичок
Джуниор
Регистрация: 28.12.2011
Сообщений: 2
|
Какого проекта? Я про ситуацию, когда еще нет никакого проекта.
Есть только pas-файл с библиотекой функций, который дальше будет использоваться в проектах. Ну или есть проект, у которого в uses этот файл есть, но сам файл в проект не включен, а лежит отдельно в папке для библиотек (как и описано в моем стартовом сообщении). В общем, как я понял, вариантов три: 1) положить этот pas-файл в папку, включенную в Library Path. Потом, когда будет скомпилирован первый проект, использующий эту библиотечку, переложить pas в папку, включенную в Browsing path, а получившийся dcu - в Library Path. 2) таки включить этот файл в первый же рабочий проект, который его использует. После компиляции удалить из состава проекта (оставив только в uses) и разложить pas и dcu по соответствующим папкам. 3) создать отдельный проект, который включает только этот модуль, в свойствах проекта прописать папку для вывода скомпилированных dcu, включенную в Library Path. Папку source этого проекта включить в Browsing path. Мне этот вариант начинает казаться наиболее стройным. При необходимости изменить библиотечку - перекомпилируем этот проект. И в этот проект можно включить все подобные одиночные файлы с разными библиотечками. |
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Ошибка no lwjgl64 in java.library.path | DTX123 | Общие вопросы по Java, Java SE, Kotlin | 11 | 30.12.2016 21:17 |
Library Path (Delphi XE8) | stlcrash | Общие вопросы Delphi | 2 | 07.05.2016 12:51 |
VS 2012 альтернатива library path | ZBEP | Общие вопросы C/C++ | 5 | 30.03.2013 17:36 |
Редактирование library path в компляторе gcc | Crystallon | Общие вопросы C/C++ | 2 | 29.04.2012 14:08 |
XE2 Library Path | Хамяг | Общие вопросы Delphi | 2 | 26.10.2011 17:36 |