[fpc-pascal] Re: [Bulk] Re: Namespaces Support
Marcos Douglas
md at delfire.net
Mon Nov 4 15:08:13 CET 2013
On Mon, Nov 4, 2013 at 10:45 AM, Dmitry Boyarintsev
<skalogryz.lists at gmail.com> wrote:
> On Mon, Nov 4, 2013 at 8:07 AM, Marcos Douglas <md at delfire.net> wrote:
>>
>> >> First, if you have a lib that have dependencies to another lib, you
>> >> have to provide all sources together -- in the same directory or
>> >> subdirectories. For this case just use the rule #1.
>> >> But, if you did not provide the sources for the other lib, the user
>> >> will need to define the "ALIAS" to the lib that have dependencies
>> >> before compile it (package). For this case use the rule #2.
>> >
>> > Changing the structure of a project is a big NO. For a number of
>> > reasons:
>>
>> There is no changes! The change is a new parameter (OPTIONAL) in the
>> compiler... just this.
>
> so again, how should rule #2 work in the following case:
> program\unit1.pas
> program\StrUtils.pas
> program\unit2.pas
> lib\StrUtils.pas
> otherlib\ExtraUtils.pas
>
> ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is not a
> subdirectory of lib.
> unti1.pas users StrUtils.pas from "lib".
> unit2.pas uses StrUtils.pas from "program"
>
> How could I compile with structure using ALIAS?
1- You need to specify the alias for compile the program (I will
invent the sintaxe now):
-ALIAS=TheLib at lib\*
-ALIAS=OtherLib at otherlib\*
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\*
3- If unti1.pas (program) uses StrUtils.pas from "lib".
uses
TheLib.StrUtils;
4- unit2.pas uses StrUtils.pas from "program" so, this is default:
uses StrUtils;
5- But you can define an alias for your program too:
-ALIAS=TheApp@*
And now:
uses
TheApp.StrUtils;
I guess that you guess that the problem is the "otherlib" to use "lib"
but you can define -- or you could -- many ALIAS for the same
directory. Thus you can define your own ALIAS for "lib" and the
"otherlib" (a 3rd-party package) can define another. ;-)
But, for me, doesn't any sense the otherlib does not know the lib's sources.
Best regards,
Marcos Douglas
More information about the fpc-pascal
mailing list