Hi,

I found that Lazarus does a great job when one uses the same lpi/lpk on different platforms. I currently have one question. If a path for example to some library folder is absolute, I get obvious non-existence error with a text "...contains a non-existing directory" (for example when letter based windows paths used and I'm in linux and press ok in project options ). I should just choose Ignore when the message appear, but I suppose for a large project it can be tedious and if I wrongly choose cancel, I can lose some information (although I can live with that). I know that I should avoid absolute paths, but sometimes it's hard to do.

I see two options (if either possible)
- Ignore absolute paths from another platform (for example c:\src found in linux Lazarus). But I'm not sure whether it's always possible.
- Introduce a setting to suppress this warning. I think if it becomes too tedious, I will be ready to switch this off completely. And it's much easier to implement that the first suggestion. I tried to find, maybe it's already there, but failed, sorry

Thanks,

Max

The third possibility is to keep your directory structure the same on all platforms, e.g. Lazarus in /usr/local/share/lazarus and your sources in /usr/local/src. If you treat a Linux system as your master, and are fairly careful about not copying stuff back from Windows unless really necessary, you won't "pollute" paths with things like drive letters.

Mark, I agree and always try to do this way, I just mentioned word "library", but I should have probably tell more. I sometimes link against c-originated libraries, and adding for example {$linklib gcc} leads absolutely different things in paths option on two platforms. Even if I manage to exclude drive letters, the expanded path from the relative one (I should choose for linking on linux) won't probably exist on windows.

Max

And/or suggest environment/ide variables that could be used :-)

-Fl?vio

Because linker paths are normally machine dependent, you can add them to your fpc.cfg.

About warnings:
The IDE should warn about strange settings after you have changed them or when someone else uses your package/project the first time. The latter case is not that easy to find out, so this is not really implemented.
Just clicking ok when you have not changed a path should not give a warning.

About ignoring absolute paths:
Wrong search paths is the top reason for frequently asked questions. That's why the warnings are there and the number of such questions have dropped since these were added. We should not ignore absolute paths in general.

Supressing:
The IDE has a mechanism to not ask questions for periods of time. For example asking a question only once per 24h or only once per project or until the IDE is restarted. Maybe
this can be used for this. But I'm not sure about the parameters.

Mattias

Mattias, interesting trick, thanks.

Yes, I thought it would tell me every time, but actually Lazarus only asks when I did something with the paths. My wrong impression was based on the fact that it warns twice, first time in the paths editor, second time - when I press ok in the project options dialog.

Great to hear it helped, interesting though that my impression from Lazarus/fpc is that they know locations better that I expect from them, I really sometimes think "ok, I know this compilation will give some _not found_ error", but it does not :)

Anyway, I'd better be live without a suppression check if it even slightly help to reduce the frequency of the same questions :)

Thanks,

Max

Does Windows still support commands like "subst" and "join"? Alternatively I believe that it does now have an equivalent of symlinks for directories.

As somebody else points out though, perhaps fpc.cfg is the best place for this sort of thing since it's not likely to be moved between systems (i.e. won't be kept in your local SVN repository or whatever).

Does Windows still support commands like "subst" and "join"?

A friend uses SUBST e.g. for his own libraries, and he cannot use FPC/Lazarus because these are unable to find his files in e.g. X:\.

Alternatively I believe that it does now have an equivalent of symlinks for directories.

NT is POSIX compatible, at least with regards to files and inodes. Symlinks exist since the introduction of desktop shortcuts/icons and the Windows Explorer, in all file systems. The implementation (of symlinks and SUBST) may vary, though, depending on the concrete filesystem.

DoDi

Why can't he use that? SUBST uses the same mechanism that is used for e.g. C:\ so all folders that are mapped using SUBST (or its underlying API) are accessible the same way from the Windows API as "normal" drives are.

But shortcuts aren't the same as symlinks. Shortcuts are normal files and they can be opened like that using e.g. OpenFile while you need to use special APIs to work on symlinks.

If you want something that is more like POSIX' symlink concept then you either need to look at the newer features provided by NTFS file systems and Windows versions like Vista and younger or you need to look at NT's object manager which can be accessed using the Native NT API and provides a virtual, object based root filesystem similar to that you can find on POSIX systems. You can also have symlinks there and in the end the drives you can see through the Window API (C:\, etc) are symlinks from the global WinAPI namespace (e.g. \Global??\C [yes, the "??" belong there]) to the correct partition (e.g. \Devices\Harddisk1\HarddiskVolume0).

Regards,
Sven

Mark Morgan Lloyd wrote

Does Windows still support commands like "subst" and "join"? Alternatively I believe that it does now have an equivalent of symlinks for directories.

Another possiblity are "drive absolute paths". If you start a path with a "\" instead of the drive name (e.g. "C:\") then the path "\lazarus" will refer to "C:\lazarus" if your current working directory is a directory on "C:\" and to "F:\lazarus" if you're currently in a directory on that drive.

This can even be used to make applications that reside on USB drives portable.

Regards,
Sven

I believe that NT introduced POSIX-compliant symlinks for files on NTFS, but that these explicitly did not handle directories. I've seen comment that this "oversight" is now fixed, but have no personal experience to confirm that.

I should test that sometimes...

But not when you use normal Windows API functions. There a shortcut file looks like a normal file. Window Explorer handles them in a special way. This is THE difference to symlinks. On POSIX basic APIs like "open" will be applied to the target of the symlink not the symlink itself.

Regards,
Sven

AFAIR FPC/RTL could not find files in a root directory, e.g. X:\myfile.pas. This may be due to the missing ".." entry in "normal" drive root directories.

Maybe, but when I "open" an shortcut to an folder, I get the folder contents, and its "properties" are the folder properties. Files may have different shortcuts/symlinks, but these can be replaced by hard links, in many cases (NTFS...).

DoDi

NTFS *Reparse Points* allow for many modifications of "normal" file handling, beyond POSIX capabilities, and IMO including true hard and symbolic links (IO_REPARSE_TAG_SYMLINK).

See also CopyFileEx, CreateHardLink, and CreateFile with e.g. FILE_FLAG_POSIX_SEMANTICS, COPY_FILE_COPY_SYMLINK or FILE_FLAG_OPEN_REPARSE_POINT.

Some of these features have been added only after W2K, as Mark annotated. It may be for compatibility reasons, or not-updated Explorer behaviour, when links and shortcuts still are stored in the old-fashion way.

DoDi

Thanks for mentioning, I also considering also this way. I use Far Manager as my file manager that always had this feature (creating hard links/symlinks). And in the project I can dedicate a platform-specific subfolder, for example $(TargetCPU)-$(TargetOS)
-liblinks, where libpath1, libpath2... links are created. The bad side is that I will lose the path information in the backups (if backup is a simple copy)

Max

Up to and including NT5.x, there were only reparse points, and they could not refer to external disks, no utility was available by default, and they were dangerous, since not correctly treated in the explorer.

Since NT6 there are true symlinks (also to external drives), an utility is delivered to created them, and the explorer supports them. Still they are not used much :_)

Some of these features have been added only after W2K, as Mark annotated. It may be for compatibility reasons, or not-updated Explorer behaviour, when links and shortcuts still are stored in the old-fashion way.

The tipping point is Vista, not XP afaik.

XP (NTFS 5.0 and higher) does support Junctions (a folder-only type of symlink). However they are unuseable on XP (unless you install a shell extension), because XP's Explorer does not handle them correctly. So few XP users are aware of Junction functionality.

Vista and Win7 have native Explorer support for Junctions as well as true POSIX-like symlink behaviour for files as well as folders. Though GUI access needs a shell extension, there is the command-line utility mklink, which confusingly (why does M$ do this?) has Source and Target parameters the opposite way round from what Linux experience leads you to expect.

Regarding those nice features of NTFS I definitely agree. Those are far more like POSIX symlinks.

But you were talking about shortcuts earlier as well and those are a different beast :P

Regards,
Sven