[nhc-bugs] Building nhc98 on Windows 2000

[C.Reinke]

> > 1) what exactly is "fullname" supposed to do in configure?
> > 
> >     if fullname 2>>/dev/null  # cope with symbolic links in directory
> 
> What it says in the comment... :-)  If `fullname' is available it
> gives the absolute pathname to its argument, i.e. it expands symbolic
> links fully in the directory part.

I can't see this under Solaris either, so the number of systems
having it might be limited?

> >     Updating targets/ix86-CYGWIN_NT-5.0/hmake3.config...
> >     fullname: not found
> 
> If your system doesn't have it, it won't be executed.  You definitely
> shouldn't see the `not found' message, because that was redirected to
> /dev/null.

?? you seem to assume that the redirection affects the executing
   shell itself, whereas, IMO, it only affects the command. so, if
   the shell can't find the command, no redirection, and the shell
   reports the error as usual, no?

> Curiously enough, the only reason I introduced `fullname' was because
> of Cygwin.  Remember the business with $(PWD) vs $(shell pwd) in
> Makefiles (Cygwin requires the latter)?  Well in Unix systems, the
> two forms give different results if there are symbolic links in the
> directory path.  Hence `fullpath' is used as a hack to try to patch
> up the difference.

I admire everyone who is fighting to smooth over incompatibilities
to produce portable systems!-)

> No, and if you look closely it isn't the line I wrote either... :-)
> It actually reads
>       $ grep '^NHC98INCDIR' ...

oops, my bad!

> I think I can see how this is failing now.  Consider this code:
> 
>     runAndReadStdout cmd = do
>         ...
>         s <- readFile output
>         removeFile output   -- file will not be removed until readFile closes it
>         return (safeinit s) -- strip trailing newline added by shell

I was indeed homing in on that strange artifact (btw, don't you want
to force the call to safeinit, so that readFile can complete and
removeFile can proceed?).

> The file-removal assumes the unix-like property that you can unlink a
> file while it still has a (lazy) reader attached to it, and the file
> contents will stick around until the reader has finished with it.
> It is perfectly possible to create a new (different) file with the
> same name as the old one whilst the old one is still being read.

Ah, I had almost forgotten about that old magic:)

Old wizards used to say: don't use magic for ordinary tasks.

It may be cute that it works on real systems, but it isn't really
needed here, so why not go for the ordinary, boring way?

> Am I right in guessing that the Cygwin filesystem doesn't have 
> these semantics?

Windows doesn't seem to agree with these semantics, so you might
not want to run your Haskell-code in plain-Windows hugs/ghc..

Cygwin itself tries to smooth things over, but there seem to be an
awful lot of ways that can go wrong. The particular problem most
relevant to our case seems to be described here:

  http://www.cygwin.com/ml/cygwin/2001-07/msg01799.html

in other words, the open-unlink-read thing kind of works, but if you
then try a write on top of it all (as in the second call to
runAndReadStdout), the current unlink hackery doesn't seem to cope
(I don't know the details, but one rumour has it that unlinks of
open files are simply queued for later removal), which might explain
the permission problem.

Forcing the call to safeinit, so that output is no longer open
via readFile when removeFile is called, should get rid of that?

Claus