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

[Dmitry Boyarintsev]

On Mon, Nov 4, 2013 at 10:06 AM, Marcos Douglas <md at delfire.net> wrote:

> On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev
> <skalogryz.lists at gmail.com> wrote:
> > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas <md at delfire.net> wrote:
> >>
> >> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is
> >> not a subdirectory of lib then the "otherlib needs to be compiled
> >> using a ALIAS:
> >> -ALIAS=TheLib at lib\*
> >
> > Ah, yes, you've mentioned the necessity for two steps compilation.
> > (compile a package first and then compile the program).
>


> This is not required is optional.
>
It is required, otherwise a wrong "StrUtils" might be used.
Or let me paraphrase that, it is required to recompile it at least once.

>
> > Which brings the necessity for external "tools" (similar to make files)
> or
> > an IDE must be smart enough to handle them.
> > (please note "an IDE", thus not refer erring to Lazarus specifically).
>
> No one compiles programs using line code options. Everybody uses a IDE
> or script for do it.
> But I did not see what the problem because it is only a new argument
> for the compiler.
>
a scripts or an IDE would need to be adjusted then.  It's not a big deal,
but it's a change.


> >> But, for me, doesn't any sense the otherlib does not know the lib's
> >> sources.
> >
> > Otherlib knows about "lib"s sources - it knows that there should be
> > "StrUtils" unit.
> > However, it doesn't know anything about there the "StrUtils" is located,
> as
> > well as it doesn't care what to do with other files of the project. It's
> > compilers job.
>
> I know. When as said "Otherlib do not known about Lib" I was talking
> about source paths.
>
Well a lib, shouldn't care about paths at all, it's compiler's job.


> If you do not change the unit names, how you can use StrUtils from
> Lib, OtherLib and program in a same unit?
>
You definitely can't. I stated that as a limitation.
That's not a purpose of the tag anyway, the purpose is to resolve
uncontrolled unit name collisions (typically introduced by changes into a
3d party lib).

If you need to mix a code from 2 units that share the same name, you'd need
to create a wrapping unit.

---code---
unit LibStrUtils

uses StrUtils;

interface

var
  procedure DoStrUtil = StrUtils.DoStrUtil;
---code---
unit Unit3;

uses StrUtils, LibStrUtils;

==code==

program\unit1.pas (uses lib/StrUtils.pas)
program\StrUtils.pas
program\unit2.pas (uses program/StrUtils.pas)
program\unit3.pas (uses program/StrUtils.pas)
program\LibStrUtils.pas (uses lib/StrUtils.pas)
lib\StrUtils.pas
otherlib\ExtraUtils.pas (uses lib/StrUtils.pas)
-- 
fpc
-SEARCH program/unit1.pas lib/StrUtils.pas   (point unit1 to use
lib/StrUtils explicitly)
-SEARCH program/LibStrUtils.pas lib/StrUtils.pas   (point unit1 to use
lib/StrUtils explicitly)
-SEARCH otherlib/ lib/ (point "otherlib" units to use any unit from "lib"
first, if found)
-Fulib
-Fuotherlib
program.pas


thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131104/187cfeaf/attachment.html>