====== Understanding MSYS / MinGW ======

**MinGW** is a port of [[http://gcc.gnu.org/|GCC]] and the [[http://www.gnu.org/software/binutils/|GNU binutils]] that produces //native// Win32 binaries.

**MSYS** is a set of libraries and tools which //emulate// a Unix-like environment on Win32.  MSYS tools are linked with a library that emulates a number of POSIX library calls which do not exist in the Win32 API, and that translates file and directory names to a more Unix-like format.  For instance, ''/c/windows'' in MSYS corresponds to ''c:/windows''.  Because of this, MSYS is //very// slow, especially when it comes to I/O operations.

The important thing is that the an application built with MinGW is a //native// Win32 application which does //not// use the MSYS runtime library and hence does //not// experience this slowdown.  However, this also means that many POSIX library functions are not available.

Microsoft's C runtime library implements a fair subset of POSIX, and MinGW adds some more (much of it as wrappers around Win32 API calls); in practice, well-written application-level code will work fine with minor changes.  The real gotchas are the bits that compile just fine but mysteriously fail at runtime, such as ''fopen()'': Windows uses ''CR LF'' line endings, so if you ''fopen()'' a binary file with ''r'' instead of ''rb'', any ''LF'' characters read from the file will be expanded to ''CR LF''.  The same applies (in reverse) when writing to a file ''fopen()''ed with ''w'' instead of ''wb''.

Let's return to MSYS's path translation.  It works like this: if an MSYS application (that is, an application linked with the MSYS runtime) calls ''open()'' or ''stat()'' or ''unlink()'' or any other library function that expects a file name, and that file name begins with a ''/'', MSYS will prepend the MSYS root (usually ''c:/MSYS''), ''unless'' the first path element is a single letter that corresponds to an existing drive, in which it is interpreted as an absolute path rooted in that drive (as in the ''/c/windows'' -> ''c:\windows'' example above).

Note that so far, I have consistently used //forward// slashes instead of //backward// slashes in paths.  Here's a dirty little secret: Windows doesn't care what kind of slash you use.  You can even mix both in the same file name.  Some of the old DOS utilities (such as ''dir'') will assume that anything that starts with a ''/'' is a command-line option, but if you steer clear of those, you'll be fine.  On the flip side, some MSYS utilities may assume that e.g. ''c:/windows'' is a relative path, since it does not begin with a ''/'' (which is precisely why path translation is necessary).

This means that whenever these instructions say something like ''/c/met.no'', you can //usually// substitute ''c:/met.no'' with impunity.  You can //not// substitute ''c:\met.no'', or even ''c:\\met.no'', because at some point or other it will end up in an underquoted string on a command line deep in a configure script, and the shell will strip the ''\''.

In fact, sometimes, you //must// use the Windows form instead of the MSYS form - specifically, when the path will end up in the finished product (either hardcoded into a binary, or somewhere in a compile-time-generated configuration file).

I'd really like to advise you to always use the Windows form, but I won't, since I can't promise that it will always work.  What I //can// promise is that it will work for Metlibs and Diana.