On 27/07/2010 13:39, Alexander Klenin wrote:
On Tue, Jul 27, 2010 at 21:48, Martin<[email protected]> 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
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
