> Even my name is written wrong.
Sorry Mattias, really.
I should use a other way to dialog, I agree it was not fun.
And I will not use directive inside code (even if it is very wow).
For close the débat, the "$UNITPATH" way works only if you add this on the
used units:
for example in the progr
On Mon, 13 Feb 2017 16:47:38 -0700 (MST)
fredvs wrote:
>[...]
> This works (Mathias way):
That's not my way. In my opinion you should not put paths into Pascal
sources and the directive should be disabled in units.
>[...]
> Congratulation Mathias, you come late, but you win.
No, I lost.
Even
> You mean a duplicate of this page
;-)
Excellent, thanks.
To resume:
This works (Michael way):
program p;
uses
unita2 in 'Documents/unita2.pp',
unita in 'Documents/unita.pp';
begin
end.
-
This works (Mathias way):
program p;
On 2/13/2017 2:02 PM, fredvs wrote:
I guess you are searching for {$unitpath Documents}
Yes, it is a excellent solution.
but then some units might not rebuild automatically,
It is not a problem, all that units are part of ../src and users should not
touch it when compiling demos.
Many than
> I guess you are searching for {$unitpath Documents}
Yes, it is a excellent solution.
> but then some units might not rebuild automatically,
It is not a problem, all that units are part of ../src and users should not
touch it when compiling demos.
Many thanks Mathias for this pearl.
PS: I
> unita2 can be anywhere.
No, if the compiler assign the directory search path, like I explained in
earlier post:
-
...
if fpcword = 'in' then begin
...
IncludeDirectorySearchPath(ExtractFilePath('/thepath/src/myunit.pas')); //
This could be added
IncludeUnit('/thepath/src/myuni
On Mon, 13 Feb 2017 09:34:09 -0700 (MST)
fredvs wrote:
> > The compiler already does this.
> Yes, that I know, for one unit, but try this:
I guess you are searching for {$unitpath Documents}
The problem with this directive is that it only works correct in the
program. FPC allows it in units
On Mon, 13 Feb 2017, fredvs wrote:
The compiler already does this.
Yes, that I know, for one unit, but try this:
That will not work, and it should not.
unita2 can be anywhere.
The compiler should not assume that the one in the Documents directory is the
one you want.
I just checked: I h
> The compiler already does this.
Yes, that I know, for one unit, but try this:
---
cadwal: >cat p.pp
program p;
uses unita in 'Documents/unita.pp';
begin
end.
cadwal: >cat Documents/unita.pp
unit unita;
uses unita2;
interface
implementation
end.
> It does. See the output I sent. Tested with fpc trunk.
Ha, you just fixed now... ;-)
OK, I will try with trunk.
Thanks Michael.
Fre;D
-
Many thanks ;-)
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/uses-myunit-in-src-myunit-pas-tp5727626p5727649.ht
> Why would you copy functionality that the OS provides out of the box ?
I profit that you are here Michael !
Not everybody knows perfectly his os.
Dealing with dynamically libraries helps to not oblige end-users to copy
files into root-protected-directories.
But, like explained, if that dynam
On Mon, 13 Feb 2017, fredvs wrote:
The compiler already does this.
Huh, then..., sorry, but there is a bug, it does not work. :-(
It does. See the output I sent. Tested with fpc trunk.
The 'in' construct was/is a serious contender for "the worst idea ever" of
Borland.
If "the compiler
> The compiler already does this.
Huh, then..., sorry, but there is a bug, it does not work. :-(
> The 'in' construct was/is a serious contender for "the worst idea ever" of
> Borland.
If "the compiler already does this" (adding the path of the unit into the
search-path list), IMO, the use of "
But thinking that the compiler itself will automagically determine the
path: that's simply not realistic.
Really ?
When the compiler reads uses section and find a "in" like here :
uses myunit in '/thepath/src/myunit.pas';
He could do something like:
...
if fpcword = 'in' then begin
Hello Graeme.
OK, thanks, I will take a look.
@Michael:
>I don't see the point at all.
I will show you later TLoadlibrary(), maybe you will see better then.
Huh, and what about: ?
>> But thinking that the compiler itself will automagically determine the
>> path: that's simply not realistic.
On 2017-02-12 18:25, fredvs wrote:
> Yes, of course it could be a solution but I would prefer something inside
> the code.
AggPas (also included with fpGUI) has a build system where relative
paths can be defined as code comments in the top of the program unit.
Relative paths are relative to the pr
16 matches
Mail list logo
