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

Martin fpc at
Tue Jul 27 12:48:43 CEST 2010

On 27/07/2010 10:32, Alexander Klenin wrote:
> On Tue, Jul 27, 2010 at 02:54, Martin<fpc at>  wrote:
>> On 26/07/2010 16:49, Martin wrote:
>>> -Fu=/path/to/lcl  // already existent, unit search path
>>> -Fa-LCL:/path/to/lcl  // define the LCL alias
>> should have been an = sign
>> -Fa=LCL:/path/to/lcl  // define the LCL alias
>> alias ends at the ":" or whatecer separator is defined.
>> ---------
>> Thinking about it, there is no need for an extra -Fa (define alias)
>> -Fu can just be extended
> Also a good idea.
> Two points:
> 1) It is very important to allow relative search paths,
> with well-defined semantics.
> Otherwise, projects would quickly become non-portable between machines.
See below: the alias is applied to the existing config , if you move 
your project to another box, that should be no problem.

If your project uses RxLib, and you want to compile it on another box => 
then RxLib must be installed ther too  (no matter in which location / path).
All that is needed is that RxLib uses the same alias, if that is part of 
the lpk file, and set to RxLib by default (by however offers the 
download), then it is the same everywhere.

If you change it on one box (because you got 2 packages with this 
alias), then you must change it on other boxes too.
You could think of all kind of fallback scenarios to ease that, but in 
hte ned, not worth the bother => how often will it happen?

> 2) Another alternative to consider is path-based namespaces,
> i.e. "uses Path.To.Lib1.Utils" would
> use unit "{project root}/path/to/lib1/utils.pas"
> The advantage is no need for extra compiler configuration.
How much extra compiler config is it i the end?

If you add a package, you must add the search path anyway. Adding the 
searchpath+alias is the same amount of work.

In Lazarus it is odne by the IDE => you add a package dependency => 
Lazarus adds the path to fpc
In future, the package *.lpk file will contain the name of the desired 
alias too.

Each supplier of a package, can put the desired default alias in there 
=> if it conflicts, the user changes it....

If you do not use an IDE, you must anyway add the -Fu to either fpc.cfg, 
or command-line => just add it with the alias

So really no work at all.

> 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.

Now you could mix this with Graeme's idea where the imported unit 
(RxLib) contains a definition of it's default namespace (if no alias is 
given in the config)
   unit Rxlib; NamespaceDefault 'Rxlib';

But currently because of the lack of a real packagem, that needs to be 
in each and every unit of the package...... Not sure about that

anyway=> even if you do, I think the ability to override it in the 
config (with the extended -Fu) is always good / it is the best way to 
deal with 2 packages wanting the same Namespace (e.g 2 zip implementations)


More information about the fpc-devel mailing list