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

Dmitry Boyarintsev skalogryz.lists at gmail.com
Sat Nov 2 15:32:21 CET 2013


Hmm, let me extend your example:

/project/unit1.pas
/project/StrUtils.pas
/lib/StrUtils.pas
/lib/ExtraUtils.pas

---code---
unit ExtraUtils;

uses StrUtils; // assumed  library StrUtils, not project
===code===
However, since StrUtils is present in project directory, it will be used
instead, causing compilation errors.

compiling with
fpc -ALIAS /lib/* TheLib

won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils

Your thoughts?

My proposal looks like this:
-SEARCH

fpc -SEARCH/program/unit1.pas@/lib/

Causing fpc to look for units at "Libs" first when compiling
"/program/unit1.pas"
No changes in any source code necessary.
With the swicth present
---code---
unit unit1

uses StrUtils; // strutils from lib
===code===

thanks,
Dmitry





On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas <md at delfire.net> wrote:

> On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev
> <skalogryz.lists at gmail.com> wrote:
> > 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;
>
> Complex...
>
> Think this:
> /project/unit1.pas
> /project/StrUtils.pas
> /lib/StrUtils.pas
>
> ===code===
> unit unit1;
>
> uses StrUtils; // local or Lib???
> ===code===
>
> To compile the unit1.pas the compiler need to know where is
> StrUtils.pas and whether to use /lib/StrUtils or /project/StrUtils,
> right?
> So, if we could to set a parameter to compiler saying:
> fpc -ALIAS /lib/* TheLib
>
> Of course I invented the "-ALIAS" parameter.
> So, returning to unit1, if we want to use the "local" StrUtils unit,
> just use the name "StrUtils". But if we want to use the Lib's
> StrUtils, then:
>
> ===code===
> unit unit1;
>
> uses TheLib.StrUtils;
> ===code===
>
> What do you think?
>
> Best regards,
> Marcos Douglas
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131102/d8e87316/attachment.html>


More information about the fpc-pascal mailing list