[fpc-pascal] Re: [Bulk] Re: Namespaces Support

[Dmitry Boyarintsev]

Technical problem:
* a unit name collision of two independent library code. Either library are
using unit with the same name. The code in the conflicting units is
different. Thus one library should use its own unit, the other should use
its own.
Since FPC allows to specify the search path for the whole compiled program,
the second library used, will be using a wrong unit (from the first
library), causing either compilation to fail or wrong code generated;

Can anyone think of any logical problems with this feature:
* allow any unit (or units under specified directories) to use their own
"unit-search" paths, than defined for the project. In that case if a
library has its own unit, the compiler will be using the library specific
unit (by finding it in the library specific search path).

>From compiler point of view - it's only a matter of where to find the
source code for the unit and how to name the resulting objects and object
file. (names must not conflict, in case some units of a compiler project
match);
Linker, shouldn't have any issues as long as objects files were created
properly;
Debugging information - no problems here, since the source file name is
specified explicitly and is typically full path;

Limitations:
* two units with the same name are not allowed to be used by any other unit
at the same time
uses unitA (from pathA), unitA (from pathB)  - not allowed;
* RTTI collisions are not to be resolved by this feature;

thanks,
Dmitry


On Wed, Oct 30, 2013 at 4:38 PM, Dmitry Boyarintsev <
skalogryz.lists at gmail.com> wrote:

> On Wed, Oct 30, 2013 at 3:45 PM, Marco van de Voort <marcov at stack.nl>wrote:
>
>> What if unitaa needs recompilation, and it is not in the dir it was
>> originally
>> compiled in. .\some\other\place then has a different meaning.
>>
>> Specially if the relative paths are short (like ..\src\ or so), there is
>> still
>> quite some room for clashes.
>>
>> That is probably the reason it is mainly used in the DPR, there relative
>> paths can be interpreted relative to the .dpr, and .dpr's are generally
>> not
>> recompiled in other directories.
>>
>
> Definitely, that's not the way to go. Since a unit source can rarely be
> adequate to the compilation environment.
>
> thanks,
> Dmitry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131101/c8077475/attachment.html>