Организация пути поиска

Question

Мы создаем через «Инструменты | Параметры | Переменные среды» такие переменные:

$(Sources) = D:\Sources\Delphi
$(OurLib) = $(Sources)\OurLib\Src
$(OurApp1) = $(Sources)\Applications\App1\3.x
$(ThirdParty) = $(Sources)\ThirdPartyComponents

Мы используем эти переменные в пути поиска проекта следующим образом:

($OurApp1)\Src\Core;($OurApp1)\Src\GUI;($OurApp1)\Src\Plugins;$(ThirdParty)\JVCL

Но это не работает (пока что исправлено) начиная с Delphi 2009, поскольку эти переменные больше не оцениваются полностью (см. QC # 73276 ). Таким образом, файлы в каталогах не найдены компилятором. Обходной путь: используйте только полные каталоги в переменных среды.

Мы используем этот подход, потому что на всех машинах разработчика и серверах сборки файлы могут быть найдены, и нам нужно только указать $ (Sources) в нужном месте.

У нас нет ничего в нашем глобальном пути к библиотеке (кроме значений по умолчанию в Delphi), потому что это не было бы в управлении версиями и не отражалось на других разработчиках или сборочных машинах.

Одна проблема: если одна единица в $ (OurLib) решит включить другую новую единицу, возможно, в новый путь, все проекты прерываются, потому что они не находят эту новую единицу. Затем мы должны пройти через все проекты и добавить путь поиска. (Кстати: я действительно ненавижу редактор пути поиска ... не будет ли простое поле заметки гораздо лучше редактировать, чем эта логика замены / добавления / удаления?)

Еще одна вещь, которую мы делаем, это не добавление большого количества юнитов в наш проект. Особенно все из $ (OurLib), но у нас часто есть такие модули, как плагины, которые добавляют функциональность только путем их включения. Для разных выпусков наших продуктов мы хотим включить разные единицы. Поскольку Delphi всегда путает $ IFDEF в предложении использования в .dpr, мы помогаем нам, включая модули, называемые «IncludePlugins», которые затем включают модули в зависимости от IFDEF. Но не включение юнитов в проект делает навигацию до боли. Модули не отображаются в проекте, они не обнаруживаются с помощью Ctrl + 12 (Показать единицы), они не отображаются при завершении кода и т. Д.

Есть ли кто-нибудь лучший способ справиться с этими проблемами?

Answer 1

Мы используем только относительные пути, любые библиотеки всегда находятся ниже подкаталога libs, а исходный код проекта находится в подкаталоге src. Таким образом, наши пути поиска всегда выглядят так:

.. \ ЛИЭС \ Library1; .. \ ЛИЭС \ library2 \ общие;

и т.д.

Все библиотеки добавляются как svn: external для каждого проекта, поэтому при проверке проекта автоматически извлекаются также библиотеки, и путь поиска всегда будет указывать на правильную версию библиотеки для этого проекта.

Не идеально, но работает большую часть времени.

Я должен согласиться с редактором пути поиска, это еще хуже для относительных путей, потому что вы не должны использовать кнопки "...", иначе Delphi вставит абсолютный путь.

Answer 2

Мы используем стандартные сопоставления дисков.

Наш текущий проект всегда включен W: независимо от того, является ли он сетевым диском или заменой.

Это прекрасно работает.

Если вам нужно поработать над другим проектом, поменяйте местами W: и вы можете продолжить.

Answer 3

Мне всегда казалось странным, что это никогда не решалось адекватно. Недавно я предложил Дэвиду I, чтобы Delphi позволил пользователю настроить какую-либо предпочтительную структуру разработки и чтобы сторонние издатели библиотек могли быть осведомлены об этом, чтобы они могли автоматически настраивать свои установщики для правильной установки в предпочтительной среде разработки. Если предпочтительная структура разработки была сохранена в файле XML или аналогичном файле, ее можно скопировать с одного компьютера на другой в команде разработчиков.

В качестве альтернативы можно создать интересный проект по созданию приложения Delphi, которое позволит пользователю «рефакторировать» установку своей библиотеки на высоком уровне. Вы указываете, какие папки в вашей системе содержат исходные или скомпилированные компоненты или что-то еще, и где вы хотите хранить исходные файлы или скомпилированные модули, нажимаете Go, и ваша система перестраивается для вас, одновременно обновляя среду Delphi, чтобы при запуске Delphi она все, что должно.

Answer 4

Вы можете скопировать путь поиска в редактор, изменить его и затем скопировать обратно.

Answer 5

Я только недавно обнаружил способ иметь специфичные для проекта переменные среды в сборках delphi с использованием XE6, он не так хорош, как полноценный #define, как в C, но, по крайней мере, теперь я могу иметь согласованные пути поиска в нескольких проектах и создайте несколько общих наборов опций.

Я настроил переменные среды так же, как и исходный плакат, а затем переопределил их в наборе параметров dproj или option.

BuildPaths.optset, добавленный в проект, выглядит как

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <SVN_Root>..\..\..</SVN_Root>
        <SVN_Riemann>$(SVN_Root)\Riemann</SVN_Riemann>
        <SVN_Library>$(SVN_Root)\Library</SVN_Library>
        <SVN_ThirdParty>$(SVN_Library)\Third Party</SVN_ThirdParty>
    </PropertyGroup>
    <ProjectExtensions>
        <Borland.Personality>Delphi.Personality.12</Borland.Personality>
        <Borland.ProjectType>OptionSet</Borland.ProjectType>
        <BorlandProject>
            <Delphi.Personality/>
        </BorlandProject>
        <ProjectFileVersion>12</ProjectFileVersion>
    </ProjectExtensions>
</Project>

Answer 6

Ваш путь поиска слишком велик. Он должен содержать только то, что вы хотите, чтобы Delphi перекомпилировала с вашим проектом. Вы действительно не хотите перекомпилировать VCL-джедай каждый день?

Я создаю один каталог, куда идут все скомпилированные модули. Скажем, C: \ dcu . Укажите это как «каталог вывода модуля» в всех пакетах. Мой «путь поиска» тогда всегда , вот так:

$(Delphi)\Lib;C:\dcu

Компилятор находит все, что ему нужно, и никогда не находит никакого исходного кода. Единственный исходный код, который он когда-либо видит, находится в файлах, которые непосредственно принадлежат любому проекту, который я компилирую. Исходные каталоги проекта не обязательно должны находиться в пути поиска, поскольку все эти файлы уже являются прямыми участниками проекта. Компилятор точно знает, где они находятся.

Для меня все исходные файлы проекта находятся в одном каталоге. Если вам нужны отдельные каталоги для разных частей, например Core и GUI , я бы поместил их в отдельные пакеты, чтобы я мог работать с ними и компилировать их отдельно. Даже если конечная программа не использует полученные BPL, пакеты по-прежнему являются хорошим способом сегментации вашего проекта и определения зависимостей.

Когда компиляция модулей для одного проекта не компилирует модули автоматически для всех других проектов, вы вынуждены менять активные проекты. Это занимает мгновение вашего времени, но также служит напоминанием о том, что вы тоже «меняете шляпы».

Хотя вы производите только один продукт , это не значит, что у вас должен быть только один проект в Delphi. У вас должен быть хотя бы один проект для каждого исполняемого модуля (EXE, DLL, BPL) в вашем продукте. Используйте группы проектов для управления несколькими проектами в одном сеансе IDE. Ни одно подразделение не должно быть участником более чем одного проекта.

---

Я не понимаю вашу часть о подключаемых модулях и различных версиях вашего проекта. Когда вы говорите «плагин», я предполагаю, что вы говорите об отдельных исполняемых модулях, таких как библиотеки DLL или пакеты, которые клиент может включить или нет. Не могли бы вы превратить функции ваших различных выпусков в подключаемые модули, которые просто не включены в меньшие выпуски? Тогда вам не нужно беспокоиться об условной компиляции вашего проекта; просто есть несколько разных инсталляторов, которые захватывают разные наборы плагинов.