uses and subdirs

[Jan_]

Hi,
i try to make something like:

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses Melodychain\intermediates\Melody0;
4.  
5. begin
6. end.
7.  

Or

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses Melodychain.intermediates.Melody0;
4.  
5. begin
6. end.
7.  

How can i make this?

Thanks Jan_

[Thaddy]

If it is a unit?

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses melody0 in 'c:\ Melodychain\intermediates\Melody0.pas'; // use full path
4.  
5. begin
6. end.
7.  

If it is not a pascal unit, you should use a resource file or link a binary version.
Otherwise you should simply load that file using a stream.

A uses clause is only for Pascal files.
Your question is not very clear.

[marcov]

While Free Pascal has  some namespace support, Pascal units and namespaces don't map on a directory structure like e.g. Java.

So in this case, best is to add those directories to the searchpaths (and/or reduce their number).

I don't recommend Thaddy's hack.

[Thaddy]

I don't recommend Thaddy's hack.

Where's the hack, Marco? The syntax suggested is common since BP7. And is the official way to do this.
I do not understand your comment.

[Jan_]

Thanks.

[Thaddy]

Marco did not have enough coffee yet.

[Jan_]

The DirectorySeparator doesn't work, do i need to things with {IFDEF...} ?

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses Melody0 in 'Melodychain'+DirectorySeparator+'intermediates'+DirectorySeparator+'Melody0.pas';
4.  
5. begin
6.   write(DirectorySeparator);
7. end.
8.                              

[rvk]

The DirectorySeparator doesn't work, do i need to things with {IFDEF...} ?

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses Melody0 in 'Melodychain'+DirectorySeparator+'intermediates'+DirectorySeparator+'Melody0.pas';
4.  
5. begin
6.   write(DirectorySeparator);
7. end.
8.                              

That's why marco suggested not to use that method.
And if you move the source to another drive or platform you need to change all the source.

That's why searchpaths are easier

[MarkMLl]

I don't recommend Thaddy's hack.

Where's the hack, Marco? The syntax suggested is common since BP7. And is the official way to do this.
I do not understand your comment.

Whether it's common or not, it can't be relied on. I've used it in the past to e.g. support an API which came in two versions where the shim files couldn't comfortably be renamed, and it caused problems.

See e.g. https://forum.lazarus.freepascal.org/index.php/topic,52884.0.html but it's part of a bigger problem which also affects incautiously-used include files etc. Unfortunately nobody's really characterised it well enough to report it as a bug (FWIW )-:

MarkMLl

[Thaddy]

Well, Mark,
The IDE of both Delphi and Lazarus does it always like that automatically in the dpr/lpr....

[MarkMLl]

Well, Mark,
The IDE of both Delphi and Lazarus does it always like that automatically in the dpr/lpr....

I believe you. Doesn't always work reliably though, hence the reports of people (myself included) who have to do a "Clean Directory" and full rebuild before changes take effect properly.

I'm in full agreement with Marco here: avoid if possible, at least until the problems are sufficiently characterised that they can be treated as a bug... and have been fixed as a bug rather than defended as arguably-correct behaviour.

MarkMLl

[Thaddy]

I obviously disagree with both of you M&M's  . It is not a hack.
I am curious that you found a "bug", Mark. Never seen it since both D1 or Lazarus...

So plz enlighten me some more...

[MarkMLl]

Discussed in the thread I cited, and a related issue occasionally raised by people having problems with $include files.

I can't remember whether the consensus was that it was an underlying FPC problem or was limited to the Lazarus IDE. But the bottom line is that "in" and "$unitpath" have various problems, see in particular https://forum.lazarus.freepascal.org/index.php/topic,52884.msg390808.html#msg390808 and the messages that follow.

MarkMLl

p.s. Please note that I am not accusing you of attempting to defend this.

[marcov]

Well, Mark,
The IDE of both Delphi and Lazarus does it always like that automatically in the dpr/lpr....

And always uses fully qualified paths there, and _only_ in the dpr/lpr.  The fact that the usage is not very universal says enough.  Projects shouldn't be forced to hardcode driveletters and global paths in the sources. What if you want to check out some release branch? The old VSS nightmare of drive substituting hacks looms again.

Delphi (tested: D6..Delphi Seattle) has some problems with partial paths, specially lower than the .dpr location. These are interpreted relative to the IDE current directory, which might not be the same as the .dpr's (e.g. after using file->open to visit a different file, or browsing to find a source file when debugging, or switching project using "recent projects". Opening a project via file-> open project always works, probably because the file open dialog (or the handler that it triggers) does set the working dir to the dir of the opened file.

So

Code: Pascal  [Select][+][-]

1. uses x in '..\y\z.pas';

I'm 100% it is for the search paths, but iirc this was also for the "in" notation.


Beside that  USES IN doesn't have anything to do with hierarchical namespaces. Which seemed to be the OP's goal.

[PascalDragon]

Well, Mark,
The IDE of both Delphi and Lazarus does it always like that automatically in the dpr/lpr....

Lazarus doesn't use the in clause by default. It supports it, but neither the default templates nor the code that adds a new unit to the project uses this clause.