Re: ghc/cygwin filename resolution issue.
Alex Ferguson [EMAIL PROTECTED] writes: (This was all motivated, btw, by trying to build HaXml under ghc/cygwin, which fell for me at the first hurdle of first catch your hmake in the recipe. I've now gotten as far as a _build_ of hmake, but it then runs into similar issues with its own use of the f/s (rc files and what-not). If anyone has this one down pat already, they might save my tired brain some pain, otherwise I'll summarise to the list if and when I get some sort of resolution myself.) I am planning to release a new version of hmake (and other tools) very soon, and would really *really* like to get these Cygwin problems licked once and for all. To this end, I have rolled a release candidate of hmake-3.07, which I would implore at least one Cygwin user, preferably a couple more, to test-drive before I make a proper release. http://haskell.org/hmake Please mail me with successes as well as failures. By the way, Claus's summary of the problem + fixes was extremely helpful, and I hope it has clarified things sufficiently for me to get it nearly right this time! Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc/cygwin filename resolution issue.
Alex As Simon M says, if you (or anyone else) felt able to write up a standalone summary of what the problem is, and what the solution is, I'd love to add it to the GHC FAQ or documentation somewhere. In my experience, simply explaining the problem clearly is quite tricky. (E.g. the cygwin vs mingw issues, described in the Building Guide, took me ages to understand well enough to write down.) Simon | -Original Message- | From: Alex Ferguson [mailto:[EMAIL PROTECTED]] | Sent: 29 January 2003 16:29 | To: [EMAIL PROTECTED] | Subject: Re: ghc/cygwin filename resolution issue. | | | | Thanks to all for the replies; Hal's resolution rings a | bell, now that I think about it, from Ye Olde Days when | cygwin was a ghc pre-req -- just didn't think of it when | installing more recently on a new machine. (Install in | haste, repent at leisure.) Claus' suggestion about relative | paths does the ticket, though: didn't occur to me as the | paths were being generated by a configure script, but yes, it | was possible to override them, which works as advertised. | | Cheers, | Alex. | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
As Simon M says, if you (or anyone else) felt able to write up a standalone summary of what the problem is, and what the solution is, I'd love to add it to the GHC FAQ or documentation somewhere. Following the worse-is-better approach, here's some text for others to fiddle with (I'd recommend to keep the result in the GHC FAQ proper, possibly with a link from the building guide, if necessary). I've omitted the build-ghc-with-cygwin option, lest readers in search or solutions rush of to cause themselves even more problems;-). Cheers, Claus Using GHC (and other GHC-compiled executables )with cygwin [background] The cygwin tools aim to provide a unix-style API on top of the windows libraries, to facilitate ports of unix software to windows. To this end, they introduce a unix-style directory hierarchy under some root directory (typically / is C:\cygwin\). Moreover, everything built against the cygwin API (including the cygwin tools and programs compiled with cygwin's ghc) will see / as the root of their file system, happily pretending to work in a typical unix environment, and finding things like /bin and /usr/include without ever explicitly bothering with their actual location on the windows system (probably C:\cygwin\bin and C:\cygwin\usr\include). [the problem] GHC, by default, no longer depends on cygwin, but is a native windows program. It is built using mingw, and it uses mingw's ghc while compiling your Haskell sources (even if you call it from cygwin's bash), but what matters here is that - just like any other normal windows program - neither GHC nor the executables it produces are aware of cygwin's pretended unix hierarchy. GHC will happily accept either '/' or '\' as path separators, but it won't know where to find /home/joe/Main.hs or /bin/bash or the like. This causes all kinds of fun when GHC is used from within cygwin's bash, or in make-sessions running under cygwin. [things to do] 0) don't panic! 1) don't use absolute paths in make, configure co if there is any chance that those might be passed to GHC (or to GHC-compiled programs). Relative paths are fine because cygwin tools are happy with them and GHC accepts '/' as path-separator. And relative paths don't depend on where cygwin's root directory is located, or on which partition or network drive your source tree happens to reside, as long as you 'cd' there first. 2) if you have to use absolute paths (beware of the innocent-looking ROOT=`pwd` in makefile hierarchies or configure scripts), cygwin provides a tool called 'cygpath' that can convert cygwin's unix-style paths to their actual windows-style counterparts. Many cygwin tools actually accept absolute windows-style paths (remember, though, that you either need to escape '\' or convert '\' to '/'), so you should be fine just using those everywhere. If you need to use tools that do some kind of path-mangling that depends on unix-style paths (one fun example is trying to interpret ':' as a separator in path lists..), you can still try to convert paths using cygpath just before they are passed to GHCfriends. 3) if you don't have cygpath, you probably don't have cygwin and hence no problems with it.. unless you want to write one build process for several platforms. Again, relative paths are your friend, but if you have to use absolute paths, and don't want to use different tools on different platforms, you can simply write a short Haskell program to print the current directory (thanks to George Russell for this idea): compiled with GHC, this will give you the view of the file system that GHC depends on (which will differ depending on whether GHC is compiled with cygwin's gcc or mingw's gcc or on a real unix system..) - that little program can also deal with escaping '\' in paths. Apart from the banner and the startup time, something like this would also do: $ echo Directory.getCurrentDirectory = putStrLn . init . tail . show | ghci 4) panic now. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Alex As Simon M says, if you (or anyone else) felt able to write up a standalone summary of what the problem is, and what the solution is, I'd love to add it to the GHC FAQ or documentation somewhere. In my experience, simply explaining the problem clearly is quite tricky. (E.g. the cygwin vs mingw issues, described in the Building Guide, took me ages to understand well enough to write down.) Simon I'll definitely defer to Claus on this one. I'm still working through the issues in places, but I don't yet have anything coherent to add. (This was all motivated, btw, by trying to build HaXml under ghc/cygwin, which fell for me at the first hurdle of first catch your hmake in the recipe. I've now gotten as far as a _build_ of hmake, but it then runs into similar issues with its own use of the f/s (rc files and what-not). If anyone has this one down pat already, they might save my tired brain some pain, otherwise I'll summarise to the list if and when I get some sort of resolution myself.) Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc/cygwin filename resolution issue.
{another candidate for the ghc faq?-}
By all means - or possibly the section of the Building Guide devoted to
Win32 builds. Would anyone like to write a concise description of the
filename issues on Windows/cygwin/GHC for the docs?
I'm certainly not an expert here, but I believe the problems stem from
trying to use pathnames that have special meaning to cygwin tools. GHC
is not built with cygwin (at least not by default) so there's no special
pathname processing going on except that '/' is accepted instead of '\',
IIRC.
I don't think you have to install cygwin in C:\. At least, my
installation is under C:\cygwin, and I'm pretty sure it worked to build
GHC last time I tried.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Alex wrote
[snip]
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some
horrible problems with inconistent treatment of filenames, especially
when using (gnu, cygwin) make. In a nutshell, make seems to be passing
paths such as /usr/local/hmake (etc) to ghc, which is, as I understand
it, interpretting these in a manner consistent with windows, but not with
cygwin. (i.e., it'd expect the above to be something like:
/cygwin/usr/local/hmake, where the root of the cygwin installation is in
c:\cygwin. Experimenting with similar arguments to ghc by hand seems to
confirm this.
[snip]
The UniForM/HTk distribution includes the attached very simple Haskell98 program,
which is compiled and run during the ./configure stage. This program transforms
stdin to stdout, globally replacing the string #PWD with whatever GHC thinks the
current directory is called. This program is used in various ways; in particular
./configure uses it to set a variable GHCTOP corresponding to GHC's name for the
top of the source distribution, which is then what gets passed to GHC. The program
is also used for various unholy tricks involving package config files, which also
of course need the Windows name.
Fortunately GHC doesn't mind if some slashes are the wrong way; thus if GHCTOP is
C:\foo\bar\uni, then I can refer to C:\foo\bar\uni\baz as $GHCTOP/baz, as
it would be on Unix.
{- This program converts stdin to stdout. It replaces all occurrences of
the string #PWD in stdin with the current directory in which it is
executed, C escaped. The string #pwd is similarly replaced, except that
it is not escaped. Everything else is left unchanged.
If an argument is supplied, this is used instead of the current
directory.
The program occupies an unusual place in the UniForM sources; it is not
part of the main sources, but is only used during building (see suffix.mk)
and is compiled during configuration. Since it only uses completely
standard Haskell 98, this ought to be pretty easy.
We do things this way rather than with some sort of script so that this
will work even in the extremely hostile environment of Windows (with no
cygwin). Also, using GHC's getCurrentDirectory means we get at what
GHC thinks the current directory is (IE the Windows file name) rather than
what it is in cygwin's Unix world.
-}
module Main (main) where
import Directory
import System
main :: IO ()
main =
do
input - getContents
args - getArgs
toInsert - case args of
[arg] - return arg
[] - getCurrentDirectory
let
escapeString s =
let
withQuotes @ ('\':rest) = show s
in
take (length rest - 1) rest
quoted = escapeString toInsert
transform [] = []
transform ('#':'P':'W':'D':rest) = quoted ++ transform rest
transform ('#':'p':'w':'d':rest) = toInsert ++ transform rest
transform (c:rest) = c:transform rest
putStr . transform $ input
Re: ghc/cygwin filename resolution issue.
Thanks to all for the replies; Hal's resolution rings a bell, now that I think about it, from Ye Olde Days when cygwin was a ghc pre-req -- just didn't think of it when installing more recently on a new machine. (Install in haste, repent at leisure.) Claus' suggestion about relative paths does the ticket, though: didn't occur to me as the paths were being generated by a configure script, but yes, it was possible to override them, which works as advertised. Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc/cygwin filename resolution issue.
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as /usr/local/hmake (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. Is there a work-around for this, or is using cygwin and ghc together just an out and out bad idea? Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
It's been a while since I've installed GHC on Windows, but I believe back when I did it (5.00 or something), you needed to have cygwin installed in c:\, not c:\cygwin, despite cygwin's protests. I don't know if this has changed, though. - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Tue, 28 Jan 2003, Alex Ferguson wrote: Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some horrible problems with inconistent treatment of filenames, especially when using (gnu, cygwin) make. In a nutshell, make seems to be passing paths such as /usr/local/hmake (etc) to ghc, which is, as I understand it, interpretting these in a manner consistent with windows, but not with cygwin. (i.e., it'd expect the above to be something like: /cygwin/usr/local/hmake, where the root of the cygwin installation is in c:\cygwin. Experimenting with similar arguments to ghc by hand seems to confirm this. Is there a work-around for this, or is using cygwin and ghc together just an out and out bad idea? Cheers, Alex. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc/cygwin filename resolution issue.
Using ghc-5.04.2 under cygwin, and cygwin (v. 1.3.10-1), I'm having some
horrible problems with inconistent treatment of filenames, especially
when using (gnu, cygwin) make. In a nutshell, make seems to be passing
paths such as /usr/local/hmake (etc) to ghc, which is, as I understand
it, interpretting these in a manner consistent with windows, but not with
cygwin. (i.e., it'd expect the above to be something like:
/cygwin/usr/local/hmake, where the root of the cygwin installation is in
c:\cygwin. Experimenting with similar arguments to ghc by hand seems to
confirm this.
Is there a work-around for this, or is using cygwin and ghc together just
an out and out bad idea?
{another candidate for the ghc faq?-}
I'd say using absolute paths is a bad idea. cygwin/ghc is my main development
environment, and mostly problem-free. The pure-windows-ghc did cause the
occasional headache with third-party tools, but the problem has so far not been
on the cygwin or ghc side, but always in unwarranted assumptions in the
construction of build processes.
In the examples I've seen of this conflict, the makefiles in question explicitly
forced the use of absolute paths at some point or other. If you absolutely have
to do this, 'cygpath' is your friend, ideally used at the places where those makefiles
insist on doing ROOT=`pwd` or the like.. (if you can't catch the problem there at
the root, you can still try to convert the paths before passing them to ghc proper,
but that might become messy).
The one occasion where this wasn't sufficient to resolve the issue was in the
case of nhc, compiled by ghc, but that was because ghc-compiled executables
also don't know about cygwin paths, and the nhc make system relies on feeding
the generated tools with absolute paths during the make process in a variety of
ways (AFAIR) - not impossible to resolve, but would be a lot of work..
[fiddling with the mount points may lead to other problems - I never saw
a reason to try that]
Cheers,
Claus
$ cygpath --help
Usage: cygpath [-p|--path] (-u|--unix)|(-w|--windows [-s|--short-name]) filename
-a|--absolute output absolute path
-c|--close handle close handle (for use in captured process)
-f|--file fileread file for input path information
-i|--ignore ignore missing argument
-p|--path filename argument is a path
-s|--short-name print Windows short form of filename
-u|--unix print Unix form of filename
-v|--version output version information and exit
-w|--windows print Windows form of filename
-A|--allusers use `All Users' instead of current user for -D, -P
-D|--desktop output `Desktop' directory and exit
-P|--smprograms output Start Menu `Programs' directory and exit
-S|--sysdir output system directory and exit
-W|--windir output `Windows' directory and exit
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
