On 27/07/2010 10:32, Alexander Klenin wrote:
On Tue, Jul 27, 2010 at 02:54, Martin<[email protected]> 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.
Only:
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)
Martin
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
