Re: Small patch for src/Makefile.am

[Anton Monroe <akm meer net>]

On Fri, Mar 23, 2007 at 07:17:08PM +0200, Pavel Tsekov wrote:
> Hmm.. I am not convinced that this patch is necessary. Why do you want
> the symlink to have an extension ? Who handles the symlinks on OS/2 ?
> Are you using some kind of a Linux/Unix emulator for OS/2 or you just
> have a set of GNU utilities ported for OS/2 ? In the former case
> it would be up to the emulator to interpret the symlink correctly
> (as is done in Cygwin), if it is the latter case I think the copy of
> the `ln' utility should do the right thing i.e. add the .exe extension
> if necessary.

I am a user, not a developer, so don't expect very technical answers.

I suppose there are really two issues.  In "$(LN_S) mc mcview" I think
the source name 'mc' has to be wrong, because the executable that was
built earlier is not 'mc', it is 'mc$(EXEEXT)'.  

Regarding an extension for the symlink itself, I hadn't really thought
about it.  I just expected that a symlink would follow whatever naming
convention the operating system used. And it is what some other apps do,
like Gawk and Ncurses. I think GNU coreutils does also, but the
coreutils Makefile is so convoluted it makes me dizzy.

As a general principle, if an operating system uses an executable
extension, the extension must say something significant about the file.
Think of a shell that depends on the extension to determine what names
to offer when doing filename completion.  It seems reasonable for a
Makefile to assume that if a filename's extension is significant, it has
the same significance when the "filename" is a symlink. But if using the
extension would break anything in Cygwin, don't do it. MC doesn't claim
to support OS/2 or any hypothetical operating systems anyway. I only
mentioned it because it looked like an oversight that affected
portability in general.

OS/2's EMX is sometimes called an emulator, but it is more like the
second situation you describe.  Unix ports can run from a normal OS/2
command line like anything else, they just need to load an extra dynamic
library.  That's the good part.  OS/2's HPFS filesystem has no symlinks,
but symlinks can be emulated by creating a dummy file with a 'symlink'
extended attribute. It's a convention borrowed from the Linux HPFS
module. The bad part of the scheme is that symlink support has to be
compiled into each application. I can create symlinks with 'ln', I can
zip, unzip, and rsync them, but I cannot execute a symlink because I
don't (yet) have a shell that understands how to resolve it.

That is why symlinks are not commonly used on OS/2.  The new GCC and
LibC may change that eventually. But for now Makefiles or config.site
scripts usually play it safe and define "LN_S = cp -p".  Naturally, when
make does "cp -p mc.exe mcview" it does not give the intended result.

Anton