условная компиляция, DEFINE в lpr

[Sergei I. Gorelkin]

Модульность - фундаментальная черта Паскаля.
Модули не зависят друг от друга, за исключением явно прописанного в секциях uses.
Каждый модуль может быть скомпилирован отдельно от проекта, и вообще может поставляться в уже скомпилированном виде, без исходников.
Отсюда следует и поведение дефайнов: они работают только в момент компиляции, и только для того модуля, который компилируется. Отсюда и необходимость вписывать их в каждый модуль по отдельности, либо передавать через командную строку.

[Alexander]

В некотором смысле так, но это скорее про Оберон. В Паскале до модулей ещё далеко, хотя раздельная компиляция уже есть.
Это в Обероне и главный файл именуется модулем: как и остальные.
Так что для Паскаля это ещё и спорный вопрос, хотя создавали его (fpc) уже когда Оберон уже существовал и скорее всего его подходы учитывали.
Ну а сами дефайны вообще поверх этого да и из Си пришли. Вариант "без исходников" рассматривать не стоит - это только отвлечёт.
Исходник нужно считать доступным. "Без исходников" это скорее из Делфи, чем из Паскаля.

[ssnakess]

Но в принципе вопрос правильный. Надо понять, что мешает разработчикам сделать дефайны в файле проекта глобальными.
Либо это не входит в представления разработчиков о Паскале, либо можно написать как пожелание улучшения или багрепорт.
Сами разработчики выходят из положения через инклюд файл, через переменные окружения и ключи командной строки.
А такого способа не предусмотрели.

Причем, имхо, но это логично, когда в файле проекта определяются общие (глобальные) для проекта define.
Т.к. писать их в Меню - проект - параметры проекта - параметры компилятора - параметры пользователя - Определения
это более чем костылный вариант
или создавать какойто файл который надо не забыть проинклудить в те юниты которые должны оперировать этими дефайнами

Добавлено спустя 6 минут 35 секунд:

Grep и find - штуки хорошие, но нафига мне ВСЕ что есть в папках лазаря? )
Список дефайнов проекта, нужен
Т.е. только тех дефайнов, которые описаны в модулях используемых в проекте (в том числе и стандартные типа sysutils, если он подключен)

Единственное что приходит в голову это парсинг, рекурсивно пройти по всем uses и получить полный список файлов.

Если не секрет, то зачем вообще это нужно?

От этих определений зависит многие варианты использования стандартных модулей, поставляемых с лазарусом, и как бы хотелось не копаться в ветвлениях юнитов, а видеть чем я как програмер могу управлять в этих модулях.
Так же Вы ставите какойто новый компонент, и я уверен на 250% что там есть определения - их не мало, а вы о них не сном ни духом т.е. для того чтобы узнать все возможности какого-то нового компонента, вам надо получается лазить по всем его модулям и выискивать дефайны, и пытаться понять - а нафига он
понятно что не все они будут окоменчены, но вы хотябы будете знать что есть определенный рычаг управления работой модуля
например в SysUtils не все дефайны откомментированны, но есть и с коментами

Код: Выделить всё

// this target has an fileflush implementation, don't include dummy
{$DEFINE SYSUTILS_HAS_FILEFLUSH_IMPL}

{ used OS file system APIs use ansistring }
{$define SYSUTILS_HAS_ANSISTR_FILEUTIL_IMPL}
{ OS has an ansistring/single byte environment variable API }
{$define SYSUTILS_HAS_ANSISTR_ENVVAR_IMPL}
                                                 


[Seenkao]

Всё достаточно просто.
Повсеместно используемые определения выписываются в основной файл (модуль).
Дополнительные определения записываются в другие файлы, где нужный файл будет использоваться в нужном модуле для определений.

Все файлы с определениями держите в одной папке. Это может быть не проект, а просто какая-то ваша рабочая папка, откуда вы будете брать файлы с вашими объявленными определениями.

Плюсы:
- все ваши хоть когда-то используемые определения будут находится в одном месте.
- вы можете взять (использовать) нужный файл с определениями в любой момент.

Минусы:
- вам надо будет самим (в любом случае) следить за объявленными и используемыми определениями. Чтоб, как минимум, они не перекрывали друг друга.

Так же, не стоит забывать, файлы с определениями вы можете использовать в других файлах с определениями.

[WAYFARER]

вам надо получается лазить по всем его модулям

Как бы так и поступаю обычно)
Никогда не задумывался что это неудобно))

[ssnakess]

вам надо получается лазить по всем его модулям

Как бы так и поступаю обычно)
Никогда не задумывался что это неудобно))

нууу, тут вот пример простой
есть модуль sysutil
и в нем кучка опредений
а он использует модуль linux
где нет определений, но например есть такое

Код: Выделить всё


{$if not defined(FPC_USE_LIBC) or defined(cpui386) or defined(cpux86_64)}



Скажите, в каком модуле определены cpui386 и cpux86_64
и на какие модули они еще влияют?

если это делать ручным поиско по uses - вы пару суток потратите и так и не найдете концов - поверьте - искал )

[Sergei I. Gorelkin]

Скажите, в каком модуле определены cpui386 и cpux86_64
и на какие модули они еще влияют?

cpui386, cpux86_64 и остальное, начинающееся с "cpu", определяются самим компилятором. Они, собственно, обозначают тот процессор, для которого компилируем. Поэтому любой код, который по каким-то причинам работает не на всех поддерживаемых процессорах, будет заключен в условие "$ifdef cpuxxx".

[Mikhail]

Надо понять, что мешает разработчикам сделать дефайны в файле проекта глобальными.

В freepascal нет файла проекта так какового. Что касается Лазарус, то там файл проекта это lpi, и в нем можно указать "дефайны" глобально для всего проекта. При использовании для сборки FPC нужно передавать такие определения через командную строку либо кастомный файл с настройками компилятора. Но вообще, правильнее, использовать какую либо из систем сборки.

[Alexander]

> В freepascal нет файла проекта так какового.

Как его не назови - он есть. Либо он просто .pas, либо явно .lpr (Lazarus Project) - отсюда и название. Речь идёт о файле в котором в первых строчках написано "program" или "library" и не написано "unit". Это в Обероне везде "MODULE" и все файлы единообразны, а в Паскале теоретически можно было бы включить что-то подобное в такой файл, но нужно ли это вопрос.

[Mikhail]

> В freepascal нет файла проекта так какового.

Как его не назови - он есть. Либо он просто .pas, либо явно .lpr (Lazarus Project) - отсюда и название. Речь идёт о файле в котором в первых строчках написано "program" или "library" и не написано "unit". Это в Обероне везде "MODULE" и все файлы единообразны, а в Паскале теоретически можно было бы включить что-то подобное в такой файл, но нужно ли это вопрос.

Нет это просто точка входа, главный модуль. Аналог файла содержащего функцию main в Си. Проект это нечто большее.

[Снег Север]

Нет это просто точка входа, главный модуль. Аналог файла содержащего функцию main в Си. Проект это нечто большее.

По-моему, это схоластический вопрос. Больше, меньше - это субъективные оценки. Если смотреть со стороны компилятора, то разницы нет.
ЗЫ. Поясню - выделение какой-то части программы в "файл проекта" нужно не ОС, а человеку-программисту, для лучшего понимания. Вот от этой печки и стоит танцевать.

[Mikhail]

Нет это просто точка входа, главный модуль. Аналог файла содержащего функцию main в Си. Проект это нечто большее.

По-моему, это схоластический вопрос. Больше, меньше - это субъективные оценки. Если смотреть со стороны компилятора, то разницы нет.
ЗЫ. Поясню - выделение какой-то части программы в "файл проекта" нужно не ОС, а человеку-программисту, для лучшего понимания. Вот от этой печки и стоит танцевать.

Файл проекта нужен для сборки приложения. lpr для этого не достаточно.

[RRYTY]

Файл проекта нужен для сборки приложения. lpr для этого не достаточно.

Если проект состоит из файлов lpi, lpr, lfm, pas и res, последние три - формы, модули и ресурсы, а lpr все дружно забраковали, то остается lpi, нет?

P.S. в настройках файловых фильтров файлы lpi так и называются - файлы проекта

[Снег Север]

Файл проекта нужен для сборки приложения.

Только потому, что создатели лазаруса так решили структурировать программу, по аналогии со "взрослыми" средами разработки, вижуал студией и делфи.

[sunjob]

по поводу "файла проекта":
какой аргумент используется для lazbuild?
правильно - *.lpr
отсюда вполне логично следует "что есть файл проекта" (если мы, конечно, говорим об лазарусе)