LPK: совпадения имен файлов.

[iN0k]

Ситуация: Есть два пакета A.lpk, B.lpk.
В каждом из них присутствует файл my_pkg_unit.pas (для каждого пакета он разный, только имена совпадают).

При попытке установить ОБА пакета ОДНОВРЕМЕННО выплывает ошибка типа:
"There are two units with the same name ... my_pkg_unit.pas ...".
Вообще говоря логично ...

вопрос: возможно ли разрулить ситуацию БЕЗ создания (переименования) файлов my_pkg_unit_A.pas, my_pkg_unit_B.pas ...

[alexs]

А зависимости не помогают? Добавить пакет А в зависимости к пакету B.
И тогда файл будет только в А. А второй пакет его увидит.

[iN0k]

не ... зависимостей нет ... это просто разные файлы с одинаковым названием

имелось в виду ...
в каждом пакете есть файл register.pas ...

вот, наверное с таким именем понятнее будет )

[resident]

А так не прокатит?
viewtopic.php?f=5&t=11083#p97181

[Лекс Айрин]

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

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

uses
  Windows, Messages, SysUtils,
  Strings in 'C:\Classes\Strings.pas', Classes;

взято отсюда http://pascal-study.blogspot.ru/2011/03 ... st_18.html

[iN0k]

тоже думаю в эту сторону ... теоретически должно помогать,
но lazarus АВТОМАТИЧЕСКИМ пересоздает файлы A.lpk и B.lpk

Добавлено спустя 2 минуты 12 секунд:
поправка... фалы "Package Source"

[iN0k]

А зависимости не помогают?

хорошо ... допустим я сделал следующее:

A.lpk и B.lpk зависят от C.lpk,
НО C.lpk должен быть скомпилирован с РАЗНЫМИ параметрами для каждого пакета (A и B) ...

такое возможно?

[zub]

Зависимости и вообще uses подразумевает использование одного и того же скомпиленого кода С в А и B.
Тут вам хочется немного странного... оформите С.pas в виде инклуда в пакете С, с соответствующей настройкой путей (в пакете С) включите его в A и B - получятся 2 разные копии скомпиленые с разными параметрами из пакетов A и B

[iN0k]

Тут вам хочется немного странного...

видимо да ...

в виде инклуда

уже и в эту сторону смотрю ... но как инклюдить форму? которая с ресурсами ... по идее она простая и можно реалТайм нарисовать ...

[zub]

>>которая с ресурсами ...
при желании всё можно, например макросами переименовать при инклуде
Но всеравно чтото тут не так и должны быть более "человечные" пути, в смысле сама задумка вкорни неправильная

[iN0k]

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

хм ... возможно ...

тогда опишу свою идею-преблему полностью:
есть компонент wndInspector_FF8S
в его структуре каталогов присутствует папка \srcEXT\ в которую я сваливаю "узко"-специализированные unit`ы, на основе (или с использованием) которых я пишу код компонента.

Теперь стоит задача создать еще один компонент, в котором можно (нужно) повторно использовать код этих "узко"-специализированных unit`ов, но возможно скомпилированных с другими параметрами.

план был такой: в новом компоненте создаю аналогичную папку \srcEXT\, Git`ом затягиваю туда "узко"-специализированные unit`ы ...

однако, фокус не удался ...

выход:
1. реальный копи-паст, однако это полная опа, я замучался править ошибки в двух местах
2. копи-паст через инклюде ... (видимо буду пробовать так)

ну или мне кто-нибудь подскажет цивилизованный способ

[Лекс Айрин]

Судя по всему, надо просто правильно составить дерево наследования компонентов/объектов.

[zub]

>>ну или мне кто-нибудь подскажет цивилизованный способ
Более цивилизованый способ - использовать повторно по нормальному))
Описание проблемы света не пролило. что за нужда использовать разные "параметры компиляции" в одном бинарнике? и что это за разные параметры?

Вангую что вам нужны генерики. но при чем здесь формы? другого разумного объяснения не вижу

[resident]

в котором можно (нужно) повторно использовать код этих "узко"-специализированных unit`ов, но возможно скомпилированных с другими параметрами.

О каких параметрах речь? Условная компиляция не катит?

[iN0k]

О каких параметрах речь? Условная компиляция не катит?

условная компиляция ... да она там постоянно ...

ок, смотрите ... есть "библиотека" SourceEditor-onActivate, она в зависимости от "параметра компиляции" {$define in0k_lazIdeSRC_SourceEditor_onActivate___inFocusONLY} ведет себя по разному.

Есть компонент wndInspector_FF8S(A.lpk) в котором эта библиотека нужна БЕЗ параметра и другой компонент (B.lpk) в котором эта библиотека нужна с параметром ...

Варианты:
1. "параметр компиляци" {$define in0k_lazIdeSRC_SourceEditor_onActivate___inFocusONLY} перевести в реалТайм и оформить "библиотеку" SourceEditor-onActivate как пакет С.lpk.
Тогда, пакеты A.lpk и B.lpk в разделе Required будут иметь ссылку на С.lpk, настраивать поведение "библиотеки" в реал тайме ... и типа все должно работать. Но у этого варианта есть минус (для меня он достаточно большой). Целевые пакеты A.lpk и B.lpk теряют "атомарность". Т.е. получив исходники пакетов A.lpk или B.lpk придется сначала искать и устанавливать пакет С.lpk. Вероятно, на данный момент, это самый правильный вариант, но мне он почему-то не нравится ...

поэтому ...
2. Ручной копи-Паст, т.е. в пакете A.lpk есть юнит UnitA.pas, в B.lpk юнит UnitB.pas. Содержимое этих юнитов ОДИНАКОВО, но за счет условной компиляции юниты "ведут" себя по разному. Неудобство в том, что исправив ошибку в одном из них, мне приходится руками копировать изменения в другой. И эта ручная синхронизация утомляет, повозившись с двумя и поняв что тоже самое теперь надо делать для трех ...

я решил попробовать следующее ...
3. Пусть теперь есть единственный UnitС.pas, он средствами Git подМодуля подтягивается к исходникам пакетов A.lpk и B.lpk. Из плюсов: "атомарность" пакета, единый источник. Но, МЕГА касяк, я не смог установить одновременно ОБА пакета (файл UnitС.pas присутствует одновременно в двух пакетах, на что Lazarus ругается плюется и не работает). Однако, по отдельности, пакеты работают именно так как я и задумывал ...

ну и теперь ... дурацкая идея
3.а. UnitС.pas превращаем в UnitС.inc, в каждом пакете снова создаем соответствующие юниты UnitА.pas и UnitВ.pas, в которых пишем {$i UnitС.inc} ... но что-то мне подсказывает что это гемор еще тот ... или я опять столкнусь с косяком из пункта 3.

ну и теперь получается: либо мои идеи и желания слишком "странные", или я чего-то не понимаю ...
потому и жажду получить дельный совет от сообщества