Hello.

There is myprogram.pas in /home/me/myproject/example.

This program uses myunit.pas from /home/me/myproject/src.

myunit.pas uses myunit2.pas and myunit3.pas that are also in home/me/myproject/src.

Using this:

program myprogram;
...
uses myunit in '../src/myunit.pas';

load indeed /home/me/myproject/src/myunit.pas but there are error messages because myunit.pas does not find the units that are in uses section.

Here myunit.pas:

unit myunit;
...
uses myunit2, myunit3;
...

How to do ?

Thanks.

Fre;D

-----
Many thanks ;-)

Unit names are considered to be unique, so strictly, for the compiler there is no need to specify the path explicitly in code when the unit path is given to the compiler when calling it from the command line.

To do this, use the -Fu parameter when calling fpc to include ../src to the unit path.

Greetings,
Tim Veldhuizen.

Hello Tim.

OK, many thanks for your light.

Fre;D

De : de la part de Tim Veldhuizen
Envoyé : samedi 11 février 2017 06:04
À :
Objet : Re: [fpc-pascal] uses myunit in '../src/myunit.pas' ?

Unit names are considered to be unique, so strictly, for the compiler there is no need to specify the path explicitly in code when the unit path is given to the compiler when calling it from the command line.

To do this, use the -Fu parameter when calling fpc to include ../src to the unit path.

Greetings,
Tim Veldhuizen.

Free Pascal - General - uses myunit in '../src/myunit.pas' ?<http://free-pascal-general.1045716.n5.nabble.com/uses-myunit-in-src-myunit-pas-tp5727626.html> free-pascal-general.1045716.n5.nabble.com
uses myunit in '../src/myunit.pas' ?. Hello. There is myprogram.pas in /home/me/myproject/example. This program uses myunit.pas from /home/me/myproject/src. myunit.pas uses myunit2.pas and...

Sent from the Free Pascal - General mailing list . _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

fpc-pascal Info Page<http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal> lists.freepascal.org
NOTE ***** Due to incidents with spambots subscribing to the list and spamming it, your first message(s) may be delayed a bit before ...

I have found some use cases for hard coded paths in the source files.. although these use cases are rare. I think even delphi main project DPR file does this, if I remember correctly, but I found other uses cases other than that. One example might be when you are writing a quick program and don't want to send in a whole bunch of -Fu options and go into dialog boxes in lazarus configuring it, so you just quickly write it in your program ../someunit instead of configuring -Fu which can be obnoxious and tedious.. But that's just one use case. Another use case, AFAIR was a build system instead of gnu make.

Indeed, I can confirm Delphi does this. I think since 2009 or XE or so, but AFAIK it doesn't need to. It does it only for the files that are explicitly added to the project, but those are also in the dproj file. And it would compile just fine without explicitly referring to the files in the dpr file, so I'm not exactly sure why it does it. Perhaps it's a kind of optimization for the caching system in the IDE..

For units that contain a form, there is also the name (value of the name property, not the classname if I recall correctly) of the form in curly braces comment behind the file reference and it seems the IDE does something with that as well. I can't remember clearly, but I recall an odd anomaly in a big application with lots of legacy that had something to do with such a comment for a unit with a form.

Tim Veldhuizen wrote

Indeed, I can confirm Delphi does this. I think since 2009 or XE or so,

I'm too lazy to check right now, but I think even delphi 5 and such used paths in the dpr (project) file

Would be interesting to find out the real reason, but once again, I'm too lazy to head down that path and post a question on stackoverflow (plus, they would likely shut it down as off topic or irrelavent, knowing those turds)

Delphi uses them just a marker for the IDE, that the units belongs to the project. It does not create different code. It uses that system since at least Delphi 3.

Mattias

In our previous episode, Lars said:

I have found some use cases for hard coded paths in the source files.. although these use cases are rare. I think even delphi main project DPR file does this, if I remember correctly, but I found other uses cases other than that.

I think that is the main reason, but that was for the IDE/designers benefit, not the compiler's. Just like the form names are mentioned in comments in the .dpr.

Later the syntax was recycled to tackle file case problems on Kylix.

But the problem is what are relative paths relative too? Project file? The actual source file?

IMHO these are all shaky uses cases, and actually doing it right is quite hard.

Why is using -Fu hard?

Mattias

In our previous episode, Mattias Gaertner said:

It requires a project file and Delphi is somewhat shaky with relative paths which makes configuring it hard. One has the choice between abs paths, the subset trick, or doubtful relative paths.

(Delphi evaluates relative paths relative to the current directory, which can be random unless you load it via file->open project)

Why is using -Fu hard?

Yes, of course it could be a solution but I would prefer something inside the code.

By the way, IMO, and it is valable for lot of languages, the way to define/use the path (of units or libraries or dependencies) is very archaic. Only LD_LIBRARY_PATH for libraries and for units I do not know if it exist.

For example, fpc can load dynamically libraries but it is not usable if that libraries depend on other libraries.

It would be great (IMO) if fpc provide, unlike other compilers, some more modern ways to use things (units, libraries, etc...) with the appropriate need-path.

But, once again, it is only a IMO.

Thanks.

Fre;D

-----
Many thanks ;-)

Loading libraries is handled by the OS, not by the compiler or the RTL and every OS has its own way to deal with dependencies.

Regards,
Sven

Loading libraries is handled by the OS, not by the compiler or the RTL and every OS has its own way to deal with dependencies.

Yes but the compiler could give some command to the os too...

Of course every OS has its own way to deal with dependencies but that is the power of fpc, he knows how to speak with those different os.

For example, TProcess also is very os dependent and it uses "environnement" parameter (that is also very os dependent).

OK for libraries, (even that I think that the compiler could help), but for units, what about create something that could define path of units used in use section...

Fre;D

-----
Many thanks ;-)

No it is not. Every OS has an environment ?

OK for libraries, (even that I think that the compiler could help), but for units, what about create something that could define path of units used in use section...

You already have such a thing: Lazarus and it's packages. In FPC, you can use fpmake and fppkg.

But thinking that the compiler itself will automagically determine the path: that's simply not realistic.

Michael.

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
IncludeSearchPath((ExtractFilePath('/thepath/src/myunit.pas');
IncludeUnit('/thepath/src/myunit.pas');
...

Fre;D

-----
Many thanks ;-)

> For example, TProcess also is very os dependent and it uses

"environnement"

> parameter (that is also very os dependent). No it is not. Every OS has an environment ?

So it is exactly what I propose:

a TLoadLibrary with some features adapted for libraries that TProcess uses for executables (like environnement).
Of course TLoadLibrary will have a LoadLibrary() and SafeLoadLibrary() but some properties too.

What do you think ?

Fre;D

-----
Many thanks ;-)

I don't see the would you copy functionality that the OS provides out of the box ?

Michael.

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 program unit. The build system then finds that info and builds the correct FPC (or Delphi) command line parameters to build the project. AggPas uses this system for all the 20+ demos it includes.

Fred, you are welcome to take a look at that too. AggPas inside fpGUI is located at <fpgui>/src/corelib/render/software/agg-demos/

Regards,
Graeme

Hello Graeme.

OK, thanks, I will take a look.

@Michael:

I don't see the will show you later TLoadlibrary(), maybe you will see better then.

Huh, and what about: ?

Fre;D

-----
Many thanks ;-)

The compiler already does this.

-----------------------------------
cadwal: >cat p.pp
program p;

uses unita in 'Documents/unita.pp';
begin
end.
cadwal: >cat Documents/unita.pp
unit unita;
interface
implementation
end.

cadwal: >fpc p.pp
cadwal: >
-----------------------------------

But honestly: you're much better off using fpmake or lazarus packages.

The 'in' construct was/is a serious contender for "the worst idea ever" of Borland.

Michael.

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 "in" should be:

uses myunit in '../src'; (in place of '../src/myunit.pas'; )

But that does not work.
I agree "in" is strange.

Fre;D

-----
Many thanks ;-)

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.

Well, you need to add the filename, and then it works.

Michael.

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 dynamically loaded library depends on other libraries you have to define the library-search path for that dependencies.

And here we come.

With fpc, that knows lot of os (unlike other compilers), with use of:

{$ifdef linux}{$define something}{$endif}
{$ifdef freebsd}{$define somethingelse}{$endif}
{$ifdef windows}{$define somethingdifferent}{$endif}
...

you may help a lot end-users (and developers)

Take a look at stackoverflow or other developer forum: "how to define path of libraries" is asked looot of times.

(2) Why would you copy functionality that the OS provides out of the box ?

Ha, then you know the command to use... ;-)

This command will be added in the TProcess used by TLoadLibrary.LibraryPath.

And this, with help of all the fpc-gurus, for each OS.

Fre;D

-----
Many thanks ;-)

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 ;-)

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.
cadwal: >cat Documents/unita2.pp
unit unita2;
interface
implementation
end.

cadwal: >fpc p.pp
cadwal: >

Fre;D

-----
Many thanks ;-)

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 have about 150 copies of frmmain.pp on my harddisk.

Unless I tell the compiler exactly which one it needs to use (using frmmain in 'XYZ/frmmain.pp'), it should not make assumptions.

so in your case:

program p;

uses
unita2 in 'Documents/unita2.pp',

    unita in 'Documents/unita.pp';

begin
end.

Should (and does) work.

Michael.

> 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 too, but then some units might not rebuild automatically, so you must rebuild always clean.

Mattias

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/myunit.pas'); // That what compiler already does ...
--------------------------

unita2 could be only in ExtractFilePath('/thepath/src/myunit.pas').

Ha, good news, I will explore that way.

____________________

I guess you are searching for {$unitpath Documents}

Oops, what's that?

I already like it, without to try it.

Many thanks for that tip, I will try it now.

Write you later.

Fre;D

uses

unita in 'Documents/unita.pp';

-----
Many thanks ;-)

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 wish that one day fpc will publish the complete list of all  the
{$something  ...} that  fpc can deal.

Fre;D

-----
Many thanks ;-)

You mean a duplicate of this page
http://wiki.freepascal.org/global_compiler_directives

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

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;
{$unitpath Documents}
uses
    unita;
begin
end.

----------------------------------------------------

This work only if changing something in compiler (Fred way):

program p;
uses
      unita in 'Documents/unita.pp';
begin
end.

-----------------------------------------------------

IMO, the winner is...

Mathias.

Congratulation Mathias, you come late, but you win.

Many thanks for that great battle.

Fre;D

-----
Many thanks ;-)

[...] 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 my name is written wrong.

Mattias

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 program:

program myprogram;
{$UNITPATH ../../src}
uses
unita;

and in the unit:

unit unita;
{$UNITPATH ./} // this add
uses
unita2;

Fre;D

-----
Many thanks ;-)

fredvs wrote

PS: I wish that one day fpc will publish the complete list of all the {$something ...} that fpc can deal.

There has always been one for local and global directives. Take a look at the official "Programmers Guide" PDF and see section 1.2 (Local Directives) and section 1.3 (Global Directives). They are all listed there with detailed descriptions.

http://www.freepascal.org/docs.var

Regards,
Graeme

This list has always existed. I wrote it:

http://www.freepascal.org/docs-html/current/prog/prog.html

Your remark shows how hard you looked for it.

Michael.

Your remark shows how hard you looked for it.

Is it the war ?

I never imagined that such local and global directives to define path of units could exist.

In my mind, it was not possible that fpc could read units without that the path was defined before all.
So only a fpc parameter could be used.

I never ask for that (I was afraid for answer-reaction like yours) nor seek to find it

And indeed, when Mattias came with {$unitpath Documents} it was a big surprise for me.

It is a difficult task to speak with gurus.
That makes me always nervous.
Sadly, sometimes when I do not find a solution, I ask it here.

But, trust me, it is always scared.

I hope that I will not annoy you anymore (but where to ask then).

Fre;D

-----
Many thanks ;-)

fredvs wrote

It is a difficult task to speak with gurus.

Nah, it's not. They are also people... I think.. Actually, I've never seen proof that they all are, so some may actually be chimps. :) Anyway, some are standing on such a high pedestal that they feel everyone is beneath them. I speak from personal experience (yes, I've been egocentric and ignorant before and yes, I met someone who was worse.. much worse). But then I guess true wisdom is to know the extent of one's own ignorance. :)
So just ask. Yeah sometimes you may get a rude response. I've had a few. So what. Their attitude is their problem, getting your question answered is yours. They help you with your answer, you help them with their attitude. You learn through the experience, they don't.

That makes me always nervous.

Don't be. Who are they to judge you? You think they never took the easy way out and ask a mailing list or forum instead of using google? At least I will admit I have once or twice. (Oh sorry guys, no I don't claim to be a guru, sorry sorry, yes yes, you are the masters. Bow, bow, kneel, kneel ;) )

Sadly, sometimes when I do not find a solution, I ask it here.

Perhaps the reason why you're not finding a solution, is because it seems to me you have a preference for a non-standard solution (at least in this occurrence). As a result, you may be searching in the wrong direction and hence, you're not finding any clear answers. (Unless I misunderstood something). But I don't fully understand your situation. I don't know what you've learned so far and what knowledge and experience you have. So I won't judge.

But, trust me, it is always scared. I hope that I will not annoy you anymore (but where to ask then).

On the contrary; I found it quite amusing. ;)

Greetz,
Tim.

Very well and eloquently written and exactly my opinion too! ;-)

fredvs wrote

> Your remark shows how hard you looked for it. Is it the war ?

No.

It just means I established you didn't look in the documentation before embarking on a mission to request a compiler extension. No more, no less.

When I learn new tools, I always read the documentation first.

I admit, there is quite some for FPC, but the list of directives is something most (if not all) programmers should be aware of.

Michael.

> I hope that I will not annoy you anymore (but where to ask then). On the contrary; I found it quite amusing. ;)

Yep, thanks Tim, I feel better now, I will continue to amuse you (and Michael too, see follow) ;-)

... embarking on a mission to request a compiler extension. No more, no less.

Yes and that mission is to adapt that un-liked "in" for something more needed.

I propose this:

uses myunit in '../src/myunit.pas'; => like now, do not touch anything at compiler.

uses myunit in '../src/'; => when no filename is defined but only a directory, add this directory in search-path like it was -Fumyunit and threat myunit like other units without "in".

Fre;D

-----
Many thanks ;-)

Please simply use "{$unitpath }" or use a lazarus project or fpc.

If anything, I would like to see "in 'xyz';" removed from the compiler. Definitely not expanded.

Michael.

Oops, in previous mail, please read:

... -Fu../src ...in place of... -Fumyunit ...

Fre;D

-----
Many thanks ;-)

Please simply use "{$unitpath }"

Huh, Mattias present me yesterday a beautiful "{$unitpath }".

We played together all the night, without any trouble.

And this morning Matt said that I may not trust in {$unitpath }, that I will only have problems, that I should think at something else. ;-(

or use a lazarus project or fpc.

The game is to do everything inside code, without external tools. (for old-way people like me that love to use console and old-fashion editors).

Fre;D

-----
Many thanks ;-)

He is correct.

But you insist on doing things wrong (in my opinion), so I oblige you by presenting you what I consider to be the least harmful option that still has a chance of earning your approval.

I am also old-way, and I also use the console.

But configuration management simply does not belong in the source code. You can use fpmake if you want to write pascal code for your configuration management. It exists for this exact purpose, and I should know, I invented it.

So, you already have plenty of options to do what you want in a file:

- lazarus project (lazbuild can perfectly be used outside the IDE)
- fppkg
- fpmake
- $unitpath
- use a per-project config file. Also a very recommended option (see e.g. fpgui)
- Probably mseide also gives you some extra options.

Given this wide range of existing tried-and-tested options, there is really no need to burden the compiler with another option.

Michael.

Just because things work now, doesn't mean they always will. Do you make software to "play" and keep yourself busy, or do you want to get to business and do something useful? If the latter option, then i think you'll want to make sure things don't break because of wrong decisions in the past. And i believe you'll want to keep things managable, simple and reusable. These are the principles that form the basis for keeping configuration such as unit search paths out of the source code.

I once restored a backup of my current project to a different directory than it used to be in and had to fix many path references as a result. (Yes even in sourcecode, because my project generates pascal code and calls fpc, so it also generates a -Fu parameter and it used an absolute path because I'm stupid and used an easy quick-fix at the time ;) ) Would you want to do that for every source file you've got?

> And this morning Matt said that I may not trust in {$unitpath }, that I will > only have problems, that I should think at something else. ;-( He is correct.

And i agree. You're not talking about a bunch of shell scripts here you see. While they are interpreted, units are compiled and some things are included into the object file which means you'd need to recompile the unit in order to use it in a safe, predictable and understandable way. The compiler usually figures out which units need to be recompiled. Configuration is therefore not something you want to put into sourcecode, as this may confuse the compiler. This may result to it not recompiling a unit, which may lead to unpredictable behaviour. That would mean your program does things that the source code cannot explain. Believe me, this is hell, I've been there. (In a project about 10 years ago, a class was being rewritten from scratch. When debugging some weird error, I noticed a variable that "magically" changed value even though it was not assigned anywhere in the source code appart from the initialisation by the constructor. It turned out to be an incorrect static cast to the old class type, in a unit that was not being recompiled so the object (of the new type) was used by that unit as if it was the old type. It cost me three days to debug this nice little beasty and because debug info was not available, i had to trace in assembly even. The cause? Configuration options incorrect. The unit was implicitly linked..)

Greetz,
Tim

Hello Michael and Tim.

Ok, you have convinced me.

But sad that the most beautiful things are always the least trustworthy.

Do you make software to "play" and keep yourself busy, or do you want to get to business and do something useful?

I make software for business and open-source. But lot of my open-source projects (https://github.com/fredvs/) are used inside the business-code.

One of my open-source project, uos, uses lot of demos, units, pascal headers, etc...
It uses now lpi (from Lazarus) and prj (from MSEide).

And I was exploring a way to write a "self-configure" code but now, thanks to you Michael, Mattias and Tim, I know that it is utopia.

By the way, like always after sending post here, I learn lot of things.

And for me, it is the only way to become richer.

So, many thanks for your gems.

Fre;D

-----
Many thanks ;-)