Hi,

Does fpc have a function that determines if a given paths is the root (e.g. '/' in Linux, 'F:\' in Windows)?
I could not find such a thing.

The Delphi converter from Lazarus needs such a function, and currently I wrote a crude one which is ifdef-ed in the source code, which we would like to avoid if possible.
(See: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/converter/convertdelphi.pas?root=lazarus&r1=38276&r2=38275&pathrev=38276 )

Bart

There is no such function.

Michael.

There is no such function.

Thanks for the quick response.

I ended up with this:

  function IsRootPath(APath: String): Boolean;
  //crude function, it maybe needs support for UNC drives
  var
    D: String;
    Len: Integer;
  begin
    D := ExtractFileDrive(APath);
    Len := Length(D);
    System.Delete(APath, 1, Len);
    Result := (Length(APath) = 1) and (APath[1] in AllowDirectorySeparators);
  end;

Bart

Bart wrote

Does fpc have a function that determines if a given paths is the root (e.g. '/' in Linux, 'F:\' in Windows)?

The question is: For what reason is this function needed? If you use "subst" on Windows you can make every path to a root path if you want.

The Delphi converter from Lazarus needs such a function,

Why?

That doesn't work for // and c:\.\ and many more combinations that all end up at the root. It doesn't work for relative paths either.

Ludo

Maybe because he wants to determine whether a path is absolute or not? So that he can e.g. convert an absolute path to a relative one so he can save this in a configuration in a more "portable" way. "subst" (or adding the path to DosDevices in the registry which is the way I prefer for persistent substing ;) ) might be a completely wrong solution or a solution where you shoot cannonballs on little birds...

Regards,
Sven

Absolute? You mean in contrast to relative? Then you only need to look for . or .. in parts of the path.

If you mean that it is the root of a disk then you cannot be sure by looking at the path because as mentioned with subst you can make any path to be a root path. If Z:\ points to c:\data\whatever then of what use is it to know that Z:\ is a root path?

So that he can e.g. convert an absolute path to a relative one so he can save this in a configuration in a more "portable" way.

For this purpose functions already exist (ExpandPath). But there is no need to know about root or not if you use them.

"subst" (or adding the path to DosDevices in the registry which is the way I prefer for persistent substing ;) ) might be a completely wrong solution or a > solution where you shoot cannonballs on little birds...

I did not write that subst should be a solution to anything. It was just an example that any path can be made a root path with subst.

No, for this there is FilenameIsAbsolute in LazUtils.

It is about scanning the directory. Juha needs a simple heuristic if the converter should search the parent directory for related files.
Apparently it is a bad idea to scan a root directory.

See
http://bugs.freepascal.org/view.php?id=22630

Mattias

Mattias Gaertner wrote

Apparently it is a bad idea to scan a root directory. See http://bugs.freepascal.org/view.php?id=22630

Well, it is a bad idea to wildly scan directory branches "just in case" at all. That's fooling so many people and there is no good reason for doing so. Only paths specified by the user (i.e. in config) should be searched. This bug reports makes it totaly obvious.
Beeing too smart is never a good idea (for a program). The only outcome of such things is that users don't understand what is happening. I would not want any program to heavily scan my disk(s) and pick up any file that seems to fit for whatever then doing things to (or with) it I cannot control anymore.

Then it is perhaps time for you to put your money where your mouth is and submit a "proper" patch?
I myself have been quite happy with the Delphi converter... and I would love to see it improved.

If that is the original problem, you could use the following check:

if ExpandFileName (APath+'..'+DirectorySeparator) ExpandFileName (APath) then ...

This is because MS Windows API happily accepts paths containing references to supposed parent directory of a root directory and silently ignores that part of the path specification. We do the same in ExpandFileName in order to remain Delphi compatible (because Delphi apparently relies on a Win32 API call for ExpandFileName whereas FPC has its own cross-platform implementation). DirectoryExists for 'c:\..\' returns true under Win32 for the same reason.

Tomas

Tomas Hajny wrote

If that is the original problem, you could use the following check: if ExpandFileName (APath+'..'+DirectorySeparator) ExpandFileName (APath) then ...

[snip]

implementation). DirectoryExists for 'c:\..\' returns true under Win32 for the same reason.

The supplied path in this scenario (Delphi converter) already is processed for any .. in it by TrimFileName() (FileProcs unit from Lazarus CodeTools).

And yes, it will not detect a substituted drive or a network drive, but in the context of the original problem, this is not really a problem.

[quote]
Your program is in directory C:\Bug4, right?
Could you try moving it one level down in directory hierarchy, for example to C:\SW\Bug4 or whatever.

The converter scans in a background thread all directories under the converted project's parent directory, searching for pascal source files. Many projects have library sources organized that way. Obviously it creates a problem if your project is just under C:\ root. [/quote]

For this the current solution will do for now.
Both Juha and me were just wondering if any such function already existed.

Given your comments, I can see it's unlikely we will have such a general function, given all the possible exceptions mentioned above.

Thanks everybody for your input.

Bart

Jürgen Hestermann wrote

Well, it is a bad idea to wildly scan directory branches "just in case" at all.

In the context of the converter it is not a "just in case" scenario.

My Delphi projects are located like this:

F:\Delphi Projecten //all my projects reside in a subfolder of this F:\Delphi Projecten\Mijn Lib //general prupose units F:\Delphi Projecten\PasParser
F:\Delphi Projecten\Endurance Calculator
F:\Delphi Projecten\HtmlEdit
F:\Delphi Projecten\etc.

So in order to find the nldlg32 unit that the PasParser project uses, the converter has to look in my "Mijn Lib" folder.

As Juha has pointed out, this is a general way projects are organized. Hence this particular search strategy.
Obviously it needed some limitation, and we have implemented that (crude as it may be).

That's fooling so many people and there is no good reason for doing so.

As explained above, there is.

Only paths specified by the user (i.e. in config) should be searched.

A valid suggestion on how to improve the converter!

Bart

Well I am not myself a user of the converter.
But even if files are organized like this, then there may be several versions of the "Mijn Lib" (or one of the units that should be found there, is also in another folder). Then the converter can't know...

IMHO, if should ask which additional path to scan, for required units. The parent dir can be set in the options, then it can be configured once and for all.

On Mon, Aug 20, 2012 at 5:47 PM, Jürgen Hestermann <

Which people exactly are getting fooled?

Lots of heuristics and guessing is involved when converting a random Delphi project.
Most projects still cannot be fully converted but the success rate can be increased with many tricks.
Scanning the parent directory improves it a lot!
The converter is not "too smart", it is rather still "too dummy" as it cannot convert all projects.

About scanning "only paths specified by the user", do you really mean the user should search for pascal sources in a to-be-converted Delphi project directories, then type the directory names into a config file and then feed that file to the converter's GUI?
IMO that is a job for the converter because its whole purpose is to automate the task. You can still do it manually if you like of course.

Did you ever try converting a non-trivial Delphi project? Try it and you get an idea of the challenges.

Regards,
Juha

The converter is clever enough to ask from user what to do with an unknown unit name.
It can be commented out or the user can search and select its location. However, scanning the parent directory makes the number of "stupid" questions lower as the obvious locations are already found.

Lazarus source editor and debugger must work accurately but Delphi conversion is all about heuristics. :)

Juha

But it could ask about certain assumptions. Like "Should I scan the parent dir", No, yes this time, yes always

Checking the root path may not be good enough. On linux you have symbolic links. On Win you have NTFS mount-points: Any partition can have zero or more drive letters, and zero or more mount points. That means that C:\ may also be found under N:\Projects\DriveC\. And then Projects could be in N:\Projects. Searching N:\Projects would obviously be to much again.

So it is very hard to tell how data is organized. Further, I have not tested, but it may well be possible to create circular mounts....

If the user can answer "Yes always" then this is a one time ask question.

True. It can also be a persistent option (checkbox) in the settings form which always opens before conversion.
I will add it.

Juha

Bart wrote

My Delphi projects are located like this: ... As Juha has pointed out, this is a general way projects are organized.

Realy? How do you know? That's just an assumption.

But my complain was more general about an increasing use of branch scanning (not only in the Delphi converter). It has become common practice to ransack each and every directory on disk in many programs based on more or less justified assumptions.

It already starts with the Windows explorer which opens all zip files in a directory to present them as directories. If you only come along this directory while navigating to a deeper level you get a long delay.

The same happens when programs look in all directories of the path environment. This has annoyed me since decades because each and every program adds directories to this variable and all these programs then search *all* these paths in case something is not found. This is not only time consuming but it also happens that *some* version of a needed file is found and used but this may be the wrong one (i.e. config files).

Why not ask the user where to find a file (or many files) if they are not found where expected? I think it is not a good idea to scan through branches that no user has said to scan.

If a file is found (and used) that was just a copy in some subdirectory with wrong data in it then the results can be wrong but the user does not know the reason because he does not know which files were used. If the user has to specify a (starting) directory he knows that 1.) a scan is done
2.) what is scanned

He meant "common", not "general".

Mattias

Juha Manninen wrote

About scanning "only paths specified by the user", do you really mean the user should search for pascal sources in a to-be-converted Delphi project directories, then type the directory names into a config file and then feed that file to the converter's GUI?

In this case of Delphi project converting it can simply ask for a root directory where to look for a missing library

IMO that is a job for the converter because its whole purpose is to automate the task. You can still do it manually if you like of course. Did you ever try converting a non-trivial Delphi project? Try it and you get an idea of the challenges.

So you mean the converter needs to know more about an existing Delphi project than the user? It should guess instead of asking?
I am not sure whether this is the right thing to do.

What is the problem to ask the user:
"I did not find a needed library xy? Please specify a branch where to search in:" Then the user can point to it and there may be an additional option "Look in this branch for other missing libraries too"

As long as the last option is not checked the user will get asked for every missing file/library and if it's in many different directories he can point to all of them. If everything is in one branch he can tag the addition option and will never be asked again. But he then knows where the sources came from.

Hi,

Please move this discussion to the fpc-other or Lazarus list, thanks.

Jonas
FPC mailing lists admin