alternative aliases [Re: [fpc-devel] Re: [fpc-pascal] Re: Ideas for namespace implementation]

[Martin]

On 27/07/2010 13:39, Alexander Klenin wrote:
> On Tue, Jul 27, 2010 at 21:48, Martin<fpc at mfriebe.de>  wrote:
>    
>>> I think that ability to use plain
>>> "fpc myproject.pas" to build the whole project is an important
>>> advantage which would be lost with your alias proposal.
>>>        
>> Not really
>> "fpc myproject.pas"
>>
>> for a project that uses RxLib, only works if RxLib is in the search path =>
>> so that needs to be set up anyway, then in future, that should always
>> contain the alias.
>>      
> This is one use case, yes.
> But another (and, for me at least, more important) use case is:
> I have (in a corporate environment) a VCS with many interdependent projects.
> All used libraries are under version control too, since they often
> contain changes not (yet) submitted upstream.
> When I do a clone, I have all required libraries in subdirectories of
> the cloned project, so I really *can* do just "fpc myproject.pas".
>
> So at least the relative paths in namespace aliases
> are an absolute requirement for me, and ability to use "ad-hoc"
> namespaces without command-line setup would be an advantage too,
> although not that critical.
>    

Ah ok, well relative pathes can be done, but question is => do they need 
the namespace (leaving out the qualified unitname in source)

if you just look at the uses clause => you do not need a namespace then 
=> you need "in" to work in units (and not only in program)
   unit foo;
   uses bar in './ralative/path' alias SomeBar;

or
    uses SomeBar = (bar in './ralative/path');
hm, here the = solution looks ugly / and in is correctly used.

----
if -Fu allows relative pathes, then a namespace can be defined there 
based on the path in -Fu

----
if local fpc.cfg files are used to setup the namespaces => they may as 
well contain relative pathes