There are also other problems with unit-search algorithm in FPC. Some of these problems:
http://bugs.freepascal.org/view.php?id=15330
http://bugs.freepascal.org/view.php?id=10551

Maybe you can take a look at these and come up with some good solution while you are there. Unfortunately, I do not have time to work on these problems at the moment, maybe in a month or so.

I know that the "in <filespec>" is part of the Delphi syntax, but what is it really good for?

AFAIK it's not allowed to "rename" units this way, and since (currently) only absolute filenames are implemented, I really wonder why FPC allows to use it everywhere?

IMO the filespec should allow for relative pathes, and also the use of FPC macros should be possible (e.g. FPCSourceDir).

When there exists interest in such an extended functionality, but nobody has the time to implement it, I'll try to implement it myself.

DoDi

Op Sun, 11 Jul 2010, schreef Hans-Peter Diettrich:

I know that the "in <filespec>" is part of the Delphi syntax, but what is it really good for?

In my opinion, it is not usefull. I have never seen a clear description of what the semantics should be, for example what happens if the code being compiled is found in the unit path, or if you point to a different directory than the current (i.e. "fpc subdir/unit.pas"). If you use it, you often also get into trouble with include files.

Another problem is that filename pathnames syntactically depend on the operating system.

In my opinion, the unit path (-Fu) is the proper way to instruct the compiler where it should search for your units. "uses ... in" is a Delphi relic we have inherited.

I am skeptical, but if you can make it more usefull...

Daniël

Hans-Peter Diettrich wrote

I know that the "in <filespec>" is part of the Delphi syntax, but what is it really good for? AFAIK it's not allowed to "rename" units this way, and since (currently) only absolute filenames are implemented,

That is incorrect. Relative file names do work. They are resolved relative to the current working directory of the compiler.

Jonas

In Delphi IDE it is needed to include a unit into the 'Find in project files' search a word in the code. This is the reason why all of your codes use this syntax.

Who said that it works only with absolute filenames? We use relative paths like '..\foo\foo.pas' or '..\..\foo\foo.pas' under Windows and it works with FPC 2.4.0 (but it already worked with 2.2.4).

Regards

Michael

11.07.2010 17:47, Hans-Peter Diettrich:

I know that the "in <filespec>" is part of the Delphi syntax, but what is it really good for?

For specifying path.
This way you are able to prevent any ambiguity in which file will actually be selected. Not sure how exactly this is implemented in FPC, but in Delphi, once you added "in ..." for all files of your interest (with correct path), you can forget about search paths altogether. (Sometimes, though not always, having search paths is less convenient, especially if there are many and if several projects share some random fractions of common files)

AFAIK it's not allowed to "rename" units this way, and since (currently) only absolute filenames are implemented, I really wonder why FPC allows to use it everywhere?

Relative paths are supported (I use them on a regular basis).

Nikolai

So what's the "current working directory"?

The only meaningful root directory is that of the unit, which uses another file - and this didn't work for me.

DoDi

The current directory when the compiler was started. E.g.:

c:\pp\src> ppc386 project\test.pas

-> "c:\pp\src" is the current working directory (aka present working directory).

Jonas

Sorry, I don't understand this strange convention :-(

How can the user of a project know, from which directory a project must be compiled, so that the relative pathes are resolved as the project author had in mind? How in detail does Lazarus know that? But it would explain why my relative unit was not found :-(

Does this mean that whole projects are recompiled, when only the compiler is invoked from a different directory, so that relative pathes are re-evaluated properly?

That's why I would restrict the usage of "in", with a (relative) path, to a program or library module, as AFAIR Delphi does, and make the directory of that file the root for relative filenames. In other units a relative path, based on an arbitrary working directory, can only lead to confusion, when the using unit is compiled for different projects - except when the directory of the using unit itself is used to resolve relative filenames in its uses clauses.

In other units it may be helpful when the filename can be overridden (alias feature). Then it's easy to exchange qualified references, by only changing the unit name in the uses clause, instead of editing all occurences of the unit name in the remainder of the code. But this is not a frequently required feature, so that "in filespec" simply could be ignored (or disallowed) in ordinary units.

DoDi

Of course. This is normal ? The compiler may find a whole different set of units if unit paths are relative. It may find units it didn't find in the first place.

'in' is only allowed in projects, libraries and packages. Anything else will lead to confusion.

It must be disallowed. It will only be a source of frustration.

The 'in' feature was introduced by borland because they made the mistake of using the main program file as project files. In later versions they corrected this, but the damage was done.

The unit alias feature was introduced to ease transition from TP for windows to Delphi.

So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place. I would not encourage it's use; the proper way to instruct the compiler where to look for units is using the -Fu switch.

Michael.

Op 2010-07-11 15:47, Hans-Peter Diettrich het geskryf:

I know that the "in <filespec>" is part of the Delphi syntax, but what is it really good for?

As far as I know, it was introduced in Delphi/Kylix to notify the IDE of what units are part of the project. Instead, Lazarus IDE does this with .lpi files, fpGUI IDE with .project files and MSEide with .prj files.

Regards,
- Graeme -

In our previous episode, Hans-Peter Diettrich said:

That's why I would restrict the usage of "in", with a (relative) path, to a program or library module, as AFAIR Delphi does, and make the directory of that file the root for relative filenames.

AFAIK it does not. Delphi projects with relative paths in library searchnames also can go horribly wrong.

Usually the working dir is equal to the project dir, but in some cases they can differ, and then it goes wrong.

The IN syntax was iirc mainly to fix certain Kylix naming issues, and to assist the designer (hence its main use in .dpr). It was abused for all kinds of trickery, but these were always hacks afaik.

Op 2010-07-12 09:01, Marco van de Voort het geskryf:

The IN syntax was iirc mainly to fix certain Kylix naming issues, and to assist the designer (hence its main use in .dpr).

As far as I know the "in" syntax was used in Delphi .dpr files, long before Kylix arrived. It was initially used by Delphi to know which files are part of a project.

Regards,
- Graeme -

Clarification:

When I start compiler\prep.lpi from Lazarus, the current directory is set to compiler\i386\, that's why compiler\prep.pas is not found.

After several tries and discussions I found that this is just the directory of the *executable*, not of the project. This is documented behaviour, but one must understand the difference between the Lazarus IDE working directory (project) and the runtime working directory (executable).

Sorry for the confusion :-(

DoDi

Michael Müller wrote

We use relative paths like '..\foo\foo.pas' or '..\..\foo\foo.pas' under Windows and it works with FPC 2.4.0 (but it already worked with 2.2.4).

Portability nightmare .....

-Michael

Michael Van Canneyt wrote

So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place.

It could be made useful when
- it takes precedence above the search path
- can bed used relative with "current" = the file it is read from
- there is an OS independent syntax (does using / and \ both as separators make sense ? )
- the (Lazarus-.usual) Variables to things like project path are usable
- ... ???

-Michael

Op Mon, 12 Jul 2010, schreef Michael Schnell:

You may be able to make it more usefull, but there still is no justification for its existance.

Daniël

The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible.

Bottom line is: don't use 'in' for the uses clause; use the command-line option to specify the location of the sources.

Michael.

Michael Van Canneyt wrote

The cure is far worse than the problem, because it is still trying to combine 2 systems that are basically incompatible.

Right you are. I was just trying to help ;).

-Michael

Then we could start by immediately flagging all uses of "in" as deprecated, unless e.g. TP7 or Delphi mode is selected. When the users can demonstrate that they still need such a feature, we could think again about other (more compatible) solutions for not yet covered special cases, before dropping it from the FPC syntax.

DoDi

I agree.

Michael.

In our previous episode, Hans-Peter Diettrich said:

See http://www.stack.nl/~marcov/porting.pdf paragraph 7 ("avoid paths...")

I originally wrote that in 2003-2004.

Even for portability purposes it often doesn't work, since usually the build systems and files for FPC/Lazarus and Delphi differ anyway (and you noticed the working dir difference)

Marco van de Voort wrote on Mon, 12 Jul 2010:

The working dir difference is a Lazarus difference, not an FPC difference. Afaict, that feature works identically in FPC and in Delphi.

Furthermore, at least two of "the users" have already posted in this thread saying that they use this functionality (both in FPC and in Delphi). Therefore I don't think it is a good idea to remove or change it.

If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Furthermore, at least two of "the users" have already posted in this thread saying that they use this functionality (both in FPC and in Delphi). Therefore I don't think it is a good idea to remove or change it.

ACK. My concern is about new users with (possibly) new uses of that construct, that will not work with the current implementation. We should cleary state that the use of the "in" feature is not recommended in new projects, and its use may lead to unexpected results.

If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning.

I don't think that unit aliasing requires a new construct. In technical terms it only affects the (one-time) comparison of the file and unit name. It *may* have more consequences, like the determination of the source file (name) from a unit name in an IDE, but I don't think that the required changes (if ever) would exceed similar comparisons. But all such considerations can be postponed, till a real and broad need for such a feature exists, or until a user comes up with an according patch.

DoDi

In our previous episode, Jonas Maebe said:

Nobody is talking about removing ? It is more a matter of not expanding, and not guaranteeing too much (more) wrt to it. Specially since DoDi in other posts seemed to state that he wanted to use it to override which unit is selected in multiple sources in path cases.

So I was not talking about IN in general, but the specific case that it actually contains paths (IOW not unit renaming).

(btw afaik the consequences of IN (but also allowing multiple casings in general) is that we don't use the OS routines to search for files, but read in the entire dir ourselves? Because one full search is cheaper than many small ones?)

If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning.

The whole paths in source is evil IMHO. It should not be expanded. The IN should remain what it was introduced for, a minimal ability to work around some case problems, and nothing more.

Marco van de Voort wrote

The whole paths in source is evil IMHO.

+1,

But id _could_ be overcome e.g. by multiple unit search passes to be defined and do something like in 2:xxx to define unit xxx to be searched in the 2nd unit search path (while no ":" means normal (1st) search path).

(Of course not compatible to Delphi at all :) ).

-Michael

Nobody is talking about removing ? It is more a matter of not expanding, and not guaranteeing too much (more) wrt to it. Specially since DoDi in other posts seemed to state that he wanted to use it to override which unit is selected in multiple sources in path cases.

AFAIR this was intended as a hack, to work around the current compiler directory tree structure. When the affected units can be moved into dedicated directories (for now in the parser_rewrite branch), such hacks will not be necessary.

DoDi

Marco van de Voort wrote on Tue, 13 Jul 2010:

It was suggested (for non-Borland syntax modes) in a quote at the top of the message you were replying to.

(btw afaik the consequences of IN (but also allowing multiple casings in general) is that we don't use the OS routines to search for files, but read in the entire dir ourselves? Because one full search is cheaper than many small ones?)

The directory cache is unrelated to the support for IN 'xxx'. It was mainly added
a) because searching directories is very slow on Windows b) indeed also because of the searching for filenames with different cases.

In case some directory in the search path contains a lot of files while only a few units are used (e.g., when doing testsuite runs), it actually slows things down though -- and quite severely so when a network file system is involved.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Jonas Maebe wrote

b) indeed also because of the searching for filenames with different cases.

It might sometimes indeed make sens to not be forced to use the same name for the unit and the file containing it's source code.

So using "in" with just a file name, without the obviously non-portable directory notation, and thus (hopefully) having the compiler search in the normal unit search path does make sense.

-Michael

Yes, but that defeats unit aliasing by renaming: like "uses foo in "bar.pas"" instead of "uses foo" (implies "in foo.pas"). Did somebody mention this in the discussion?
Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content.....

In our previous episode, Thaddy said:

I really wonder what the point is of such hack. You still have to walk all references to add ( in ' '), so you might as well do a proper rename.

In the past it was sometimes used to have long unit names refer to 8.3 filenames, but I haven't really cared about 8.3 for almost a decade now.

Marco van de Voort wrote

In our previous episode, Thaddy said:

Ok, you write always cheerful, I was merely pointing out it is not clean, but useful :))

I prefer to use search path instead of "in", but I think it's a good idea to use aliases for units. As Thaddy said "Programmers are not very imaginative in naming". I agree.
I always nominate my units with prefix to haven't name conflicts with other units.

MD.

Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content.....

Just in the FPC compiler case many unit names are hard coded, while the files to use reside e.g. in a specific machine directory, selected in the search path. When it becomes desireable to replace only one of these files, as happened to me, then a solution could be to name that replacement file differently from its contained unit name.

Then it would be helpful to allow for exchangable file names, at least at project/program level. Only then one can be sure that a specific file is used across the entire project, regardless of all other files in the search path.

DoDi

I am surprised as there is no conflict of names of units in the FPC / Lazarus. There are names very short, which could be used as variable names...

MD.

Marcos Douglas wrote

I am surprised as there is no conflict of names of units in the FPC / Lazarus. There are names very short, which could be used as variable names...

Is there, still, a platform (where FPC can be used) that restricts filenames to being so short?

Cheers,

Adem

2010/7/14 Adem :

I don't know... but I like short names. I prefer (in many cases) to use the sintaxe
unit.function() or unit.obj or unit.const, etc. to not have conflicts names, however
if a unit name has a short (and conflicting) name, the problem remains.

MD.

Of course there are. For example unit dialogs. This is solved by the search path.

There are even conflicting names in the system unit. For example the system unit has a THandle that is 32bit under linux 64bit, but Lazarus needs a THandle that is 64bit under 64bit. Gladfully the system unit is searched last.

There are names very short, which could be used as variable names...

Mattias

And if do you have your own unit Dialogs too, what you do?

MD.

Me? I would rename my unit.

Mattias

Hum... Okay, but if this unit (Dialogs, in your example) is part of another framework, not yours?

MD.

I would tell the devels of the framework.
And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both.

Mattias

Then, another example:
You want to work with ZIP and RAR format files. So, imagine you found, on the net, 2 libs, one for each type format. The problem is each lib uses the same name to main unit e.g. zip.pas.

Both libs are very used by million of people on the world and they, the developers do not want to change the name of yours unit.

And now, you understood the little problem?

MD.

Do you have the links to the two projects?

And now, you understood the little problem?

Of course I understand the problem, but I have not yet encountered it in a real project.

Mattias

No, that was an example...

> And now, you understood the little problem? Of course I understand the problem, but I have not yet encountered it in a real project.

So, if we can to put an alias to unit names, there are no more problem. I had this problem in real projects. Always happen with the units that have very short names or names that are very generic. Therefore, most of the frameworks put a prefix in the units.

BTW, I use "my" prefix for units of project (e.g. myparser, mytextutils, mydb, etc).
If I create a lib, I choose other prefix.

MD.

In our previous episode, Marcos Douglas said:

I would say thats is a pretty strange situation, since those million people will all have the same problem, and won't like adding xxx in 'yyy' to all uses, and edit one of those packages to fix that everytime a new release comes out.

In our previous episode, Marcos Douglas said:

Note that the " in" syntax is not a cure all similar to prefixing and making sure that that all filenames are unique. This because there are still two units with the same name in the searchpath, and one mistake in fixing the uses clauses will cause problems.

Moreover, I agree mostly with Mattias in that dealing quickly with rare cases is a lot less work then heavy handed approaches to 'fix' the problem.

Remember, this is an example...

... and won't like adding xxx in 'yyy' to all uses, and edit one of those packages to fix that everytime a new release comes out.

Exactly!

You're right :(
And if we can do that:
uses

  zip IN '/units/my/zip.pas' AS myzip;
  zip IN '/units/lib/zip/zip.pas' AS ziplib;

Now, I can point the real path and I can use 'n' units with the same name. What do you think about it?

Moreover, I agree mostly with Mattias in that dealing quickly with rare cases is a lot less work then heavy handed approaches to 'fix' the problem.

Yes, I agree with you.

MD.

create a rar.pas containing only the line:
  {$include rar/zip.pas}

compile with:
fpc -Un rar.pas

-Un Do not check where the unit name matches the file name

regards
Stefan

In our previous episode, Marcos Douglas said:

Still the same problem. If you forget one, or do one wrongly, it will become a mess. Better avoid the mess altogether, and keep unique names.

Moreover, everybody still has to edit everything to substitute their own paths.

Interesting...
Anyone ever used this?

MD.

Not still, you know... ;-)
But I agree it will (maybe) become a mess. However this would be an option (not default) for this some cases. Considering that "in" syntax is still existing... ;-)

Well, just my 2 cents...

MD.

Hi!

Adem wrote

Is there, still, a platform (where FPC can be used) that restricts filenames to being so short?

FPC still supports DOS, which only supports 8.3 filenames, if I'm informed correctly. (Can someone comment on FreeDOS regarding this?)

Regards,
Sven

I'm still using it. Or make a symlink:
ln -s rar/zip.pas rar.pas

In combination with {$L xzy.o} and 'external name ...' you can do
wonderful things. Don't do this at home! (maybe at work :-)

Stefan

Hello Mattias,

you wrote

> And now, you understood the little problem?

MG> Of course I understand the problem, but I have not yet encountered MG> it in a real project.

I can vaguely remember a case like this in Delphi several years ago, but I think the problem was a precompiled .dcu which I can not rename. Is this possible ?

Sven Barth wrote

(Can someone comment on FreeDOS regarding this?)

If it's file system provides ;MS-DOS-style long filenames, users of same might be sued by M$ (like TomTom).

-Michael

Stefan Kisdaroczi wrote

Or make a symlink:

Happily even Windows NTFS does support symlinks, even though hardly anybody uses this. ;)

-Michael

Hi!

Michael Schnell wrote

On 07/14/2010 09:40 PM, Sven Barth wrote: > (Can someone comment on FreeDOS regarding this?) If it's file system provides ;MS-DOS-style long filenames, users of same might be sued by M$ (like TomTom).

But why should they sue an open source MS-DOS clone when they're trying to get their costumers to upgrade to Windows 7? I'd more "understand" if they'd sue ReactOS in the near future... or Linux, because it is "the root of all evil".

Regards,
Sven

But why should they sue an open source MS-DOS clone

[snip]

Please take that discussion to the fpc-other list.

Jonas
FPC mailing lists admin

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Okay... this is very sophisticated. I have not used it (yet) but this is not so simple.
I still thinking my sugestion (in other mail, and copied below) is a good way:

uses
 zip IN '/units/my/zip.pas' AS myzip;
 zip IN '/units/lib/zip/zip.pas' AS ziplib;

2 units, same name, different paths and different "aliases" to use in project.

José Mejuto wrote

I can vaguely remember a case like this in Delphi several years ago, but I think the problem was a precompiled .dcu which I can not rename. Is this possible ?

...but my sugestion do no serves for compiled files... or serves?

Regards,
MD.

What is the 'zip in' good for?

2 units, same name, different paths and different "aliases" to use in project.

It means the compiler must rename all internal names of at least one of the units and must adapt all .o files that use that unit. What should the compiler do, if it finds a unit that "uses zip;"? Which one should it use?

Mattias

This is a sugestion of sintaxe, if you have 2 units with the same name...

In my example, a compiler error would happen because you would used 'uses myzip;' or 'uses ziplib;'
Again, this is a suggestion... I do not understand so much of compilers. If this not possible, is Okay for me.

MD

It is more useful if relative to same directory of the current file, i can move or copy my projects/lib easly without need to change the .cfg or my project options.

Best regards

Zitat von Zaher Dirkey :

Even then: If you move/rename a directory with target units, you have to adapt all 'in' of using units.
If you use search paths you only have to adapt one.

Mattias

2010/7/19 Mattias Gärtner

Even then: If you move/rename a directory with target units, you have to adapt all 'in' of using units. If you use search paths you only have to adapt one.

example

uses
myunit in '..\lib\myunit.pas', ...

it is no need to change it even in the search path.

uses

I meant my project have folders like
/proj/bin
/proj/src
/proj/lib
i can move the dir /proj or my component package to any dir without need a changes.

The other way we can use extrafpc.cfg, we can put relative path in "-Fu..\lib", but if you use units of packages you need to put many of pathes

Best regards

I agree.
But I agree too the search path has advantages... because that I mentioned keep the both (today, it is, right?).

And, in addition, I sugest to implement a new syntax for units of the same name using "IN" and "AS" as bellow:
uses
zip IN '/units/my/zip.pas' AS myzip;
zip IN '/units/lib/zip/zip.pas' AS ziplib;

...someone liked the idea? :(

MD

So it is with search paths. They don't need to change when you move your /proj.
I don't see your point.

The other way we can use extrafpc.cfg, we can put relative path in "-Fu..\lib", but if you use units of packages you need to put many of pathes

Or use lazarus or msegui or makefiles or whatever build system you prefer.

Mattias

On Wed, Jul 21, 2010 at 8:37 AM, Mattias Gaertner <

If i have project use some source of components,not use *.o files, My proj1 use component lib1.pas but lib1.pas need unit unit1.pas in sub dir (/mylib/src/sqlite/unit1.pas) of same dir of lib1.pas

/proj1/bin
/proj1/src
/proj1/lib
/proj1/addons

/mylib/src
/mylib/src/sqlite/
/mylib/src/firebird/

in fact i must add all in search path, while if i put in /mylib/src/lib1.pas in uses
uses

  sqlite in './sqlite/sqlite.pas';

now i can move copy to friends, make it from another platform (linux/windows) and send the examples without worry about the paths, may be i need to change one path

May be the point got when i build site using PHP :)

Thanks

Changing a search path is simple.
And with Lazarus projects/package you don't even have to adapt search paths when moving projects/packages on disk or to other computers.

But when you move some units around in your project, then you must check all 'in'. With search paths you only have to check one place. And again Lazarus and MSEGui helps you here.

May be the point got when i build site using PHP :)

I still think, search paths are in almost all cases easier and more powerful than 'in'.

Mattias