Во-первых, если во время компиляции найдётся два модуля с одинаковым именем, то использован будет только один, первый встетившийся.Ну например:
- Код: Выделить всё
Main.pas
a\Unit1.pas
b\Unit1.pas
При этом a и b будут в списке путей. Компилятор тогда возьмёт первый встретившийся модуль. Таким образом, если Main использует Unit1, то возьмётся aUnit1.pas.
А если так:- Код: Выделить всё
Main.pas
a\Unit1.pas
b\Unit1.pas
b\Unit2.pas
Если Unit2 использует Unit1, то всё равно возьмётся a\Unit1.pas, хотя по логике должен наверное взяться модуль, который лежит "ближе", то есть, в той же папке, то есть, b\Unit1.pas. Но это не так, я проверял, будет всё равно браться a\Unit1.pas.
К тому же, при компиляции одного проекта все скомпилированные модули выводятся в один каталог. То есть, если будет два Unit1 в разных папках, то при компиляции они никак не разойдутся, так как Unit1.ppu и Unit1.o по идее должны вывестись в одну и ту же папку для вывода, которая в лазарусе по умолчанию в lib... . Даже если компилировать проект в две стадии, то и это не спасёт, так как для компиляции исполняемого файла нужны все .o-файлы, так что, такая штука:- Код: Выделить всё
a\Unit1 + a\Unit2 -> UnitA
b\Unit1 + b\Unit2 -> UnitB
---
UnitA + UnitB -> Main
не пройдёт, ведь для Main.exe понадобятся и Unit1.o и Unit2.o, из обоих папок, а так быть не может потому, что они затрут друг друга.
К какому же выводу это приводит: лучше стараться всегда придумывать уникальные имена для модулей, иначе они могут пересечься, и тогда придётся их переименовывать, чтобы заставить компилироваться вместе. Причём работа по переименованию может оказаться достаточно дорогостоящей, ведь нужно переименовать и файл, и объявление в начале файла: unit Log; например, и все все ссылки на этот модуль: uses Log. Причём пройти автозаменой в этом случае не получится: вдруг где-то есть переменная var Log: TLog, которую переименовывать нельзя...Таким образом, если в двух библиотеках будет модуль log, то вместе они не уживутся никак. Даже если log используется библиотекой только внутренне самой библиотекой и не входит в её функциональность. Не поэтому ли во всяких библиотеках в начале модуля приписывают префиксы типа gls для GLScene, fpg для fpgui и проч.
Дополнительная проблема, которая может быть вызвана неудачным именем модуля, заключается в следующем: если используется модуль log, то объявить переменную с именем log уже не получится, будет конфликт имён. Я видел, что некоторые приписывают u к названию модуля, типа uLog. Наверное чтобы избежать конфликтов с именами переменных и функций.
А теперь собственно "главная" проблема, в некотором роде: допустим, я решил давать всем модулям уникальные имена. Мне не лень их набирать, так как я хочу сразу избежать двух проблем: конфликтов имён; и так же ещё чтобы потом не пришлось догадываться, что значат сокращения. То есть, вместо gls я пишу GLScene, вместо ctnrs пишу Containers и так далее. Ну и ещё я не хочу чтобы имя модуля совпало когда-нибудь с именем переменной, для этого я приписываю Unit в конце каждого модуля. Что тогда получается: имена модулей у меня получаются примерно такие:- Код: Выделить всё
GLSceneContainerUnit.pas,
GLSceneAbstractContainerUnit.pas
GLSceneNetworkLogWriterUnit.pas
...
GLSceneAbstractDataBaseConnectionProviderUnit.pas
Так вот: то, что имена модулей длинные сами по себе, это не такая уж и проблема. Проблема в другом: в Windows есть интересное ограничение на максимальную длину пути: 260 символов. И не смотря на то, что в NTFS максимальная длина пути вроде бы 32000, и от ограничения в 260 символов хотели как будто бы уйти, так вот, по факту от него никуда не ушли: оно везде лезет. Можно даже попробовать в Windows 8 создать папку с длиной имени 260 символов, и он не даст. Причём ограничение касается не одного файла, а всего пути. То есть, если будет вот так:
C:\1234.....259\a.txt
То файл a.txt окажется недоступным. То есть, если засунуть свою библиотеку с длинными именами файлов в какую-нибудь "жопу" типа
C:\MountedDrive\Storage\Archive\Programming\FreePascal\Libraries\GLScene\Source\GLSceneAbstractDataBaseConnectionProviderUnit.pas
То если таким образом "переборщить", то будет всё очень плохо
Таким образом, остаётся либо делать короткие имена типа connection.pas и рисковать получить 100500 конфликтов
Либо делать сокращения типа uGLSABDConProv.pas и потом вспоминать что же это значит
Либо делать длинные имена файлов и надеяться что полные пути никогда не вылезут за 260 символов. Либо работать только на линуксе, так как там такого ограничения нет.
Ну и воттттъъъъ........ кто-нибудь может что-нибудь посоветовать
Добавлено спустя 7 минут 9 секунд:
ну или вообще что-нибудь изложить по этому поводу
