Re: binding to C libraries on Windoww
To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either. While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive. Even then, there's no guarantee the right version will be found (google "DLL Hell" for examples of the chaos that ensues). This is particularly true for developers, who frequently have multiple versions of libraries installed. The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers). On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step. One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it. C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model. MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows. Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows. John
To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, such as C:\Program Files\, the user's home directory, the system directory, or directly off the drive root. Defaults are not common among different programs or even versions of programs, and install locations are frequently changed by users anyway. Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either.
If Windows lacks a sane environment, why not to provide one? I don't know how much of it mingw already provides. If it doesn't, that would be a nice Haskell project :) It could be called Windows SaneEnvironment, and include a few basic policies for packages and a package manager. When I needed Windows myself I would certainly help maintaining. It would not be hard to find others who still will. Maurício
John Lato wrote:
To reply to an earlier point of Andrew's (I can't find the quote now, sorry), one of the biggest difficulties developers face on Windows is the lack of common install locations/practices. Windows software is usually distributed as a binary, which may or may not include header files. These files may be installed in any of numerous locations, Libraries and headers are usually not located on the PATH environment variable, and there's no standard INCDIR or LIBDIR variable either.
Agreed.
While it is Cabal's job to find the location of necessary libraries, header files, and tools, there simply is no feasible way to do so on Windows without searching most of the hard drive.
Also agreed.
The only workable approach is to have users specify the locations of these files, which unfortunately requires more sophistication than can be expected of most Windows users (and even some Windows developers).
Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry), or possibly the *developer* package comes as a simple Zip file that you just unzip to wherever you fancy. Just tell the user the URL to grab the Zip file from, unzip it and tell Cabal where the root is now. Shouldn't be too hard. (Famous last words...) The problem, of course, is that, especially if the file layout differs significantly in the Windows version of the library, this is going to absolutely _require_ somebody with a real Windows box and familiarity with Windows to work on the Cabal packaging. (In extreme cases you might even end up needing a completely seperate, Windows-only Cabal file.) Presumably nobody will ever have the time or inclination to construct this.
On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step.
Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it. I gather it's supposed to be Cabal's job to figure this stuff out in Haskell land?
One last wrinkle: many distributors of C libraries do not have Windows machines available to test, and (understandably) have little interest in supporting a platform they don't have and aren't familiar with. As a result, many C libraries are not well supported on Windows and require somebody familiar with gnu build tools (i.e. gcc, make, and autoconf) to be usable on Windows *at all*. This means that, as a Haskell developer wanting to use these libs, you need to use gnu build tools because you're not just binding to the library, you're maintaining a Windows port of it.
This seems to be kind of the catch-22. Nobody uses Windows, so there isn't much support for Windows, so we don't attract many Windows users... QED. :-}
C and unix are pretty much designed to work together, and have been for decades, so I think it's reasonable to expect that Windows is the side that needs to adapt to support their model.
In other words, "Windows needs to become just like Unix". Not going to happen. ;-) Argue about whether this is good or bad amoungst yourselves. But it's not happening.
MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows.
I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though.
Cross-platform support precludes windows-native solutions, so you're left making the best of it with Linux tools (mingw and cygwin) on Windows.
Yeah, it seems for the time being any Haskellers wanting to work on Windows have to choose either to not use external C libraries or to install the entire GNU toolchain. *sigh*
Andrew Coppin wrote:
Well, I don't know. It's going to vary from package to package, but most things that have a semi-official Windows version either come as a Windows Installer package (which, one presumes records where it put everything *somewhere* in the Windows registry)
Is that done automatically or does the installer have to explicity set it? What does it look like? The reason I ask is that I release a binary windows installer for libsndfile. The binaries are generated using a Linux to Windows cross-compiler and for the win32 version I run the testsuite under Wine (windows API emulator). I then run INNO Setup under wine to generate the installer executable.
On a related matter, many packagers resort to using configure-style configuration setups to assist with binding to C libraries. Cabal is now sophisticated enough to handle many of these steps (although not all), however packagers may not have had an opportunity to update their build process to remove the dependency on "configure". These packages will continue to require cygwin or mingw for the "configure" step.
Ah yes, this is pretty much guaranteed to make stuff not work on Windows. :-) Still, all Unix systems have Automake, configure, etc., so I guess most people don't even think twice before using it.
There are bigger problems than that. The Microsoft compiler still doesn't support large chunks of the 1999 ISO C Standard. There is stuff in that standard that makes my life easier so I use it in libsndfile. Its also why I much prefer to cross compiler from Linux to Windows with a GNU compiler that supports the vast majority of the 1999 ISO C Standard. I would be possible to make libsndfile compile with Microsofts compiler but it would add a whole bunch of #ifdefs all over the place making the code base fragile and in the long term less maintainable and reliable.
MS hasn't done so, which means that C developers would need to unacceptably compromise unix support in their packages in order to better support Windows.
I don't know about that... Lots of commercial and open-source products are available for Windows and Unix, seemingly without any problem. (GTK, for example...) I don't deny that adding Windows support is _a lot more work_ than adding support for just another Unix, though.
Ignoring bugs and features that are common across all platforms in libsndfile I have spent at least an order of magnitude more time and effort getting things working with windows that I have with all of the Unixes (including OSX) summed together. This for a platform I don't use.
Yeah, it seems for the time being any Haskellers wanting to work on Windows have to choose either to not use external C libraries or to install the entire GNU toolchain. *sigh*
If those libraries use parts of the C99 standard then yes. Microsoft has had 10 years to make their compilers compliant. Ask them why they haven't. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Erik de Castro Lopo wrote:
There are bigger problems than that. The Microsoft compiler still doesn't support large chunks of the 1999 ISO C Standard.
Seriously? OK, well that's news to me. I was under the impression that practically all C compilers in existence support the same set of features. (Although I'm sure each one probably has a few non-standard additions too.)
There are several C standards by year of publication. There are also drafts
of those standards. A C compiler may comply with a draft of the official
standard before it became official, but not the official standard itself.
Rarely does anyone seek full compliance with respect to any standard it
seems and it can take years before everyone has bother themselves enough to
bring themselves up to speed with whatever the current standard is supposed
to be.
I use the Microsoft CL compiler (aka Visual C++). It has some undocumented
quirks/optimizations, but for the most part if you are doing native
development it seems fine. It is the official compiler so you just have to
learn to love it.
The problem seems to be if you are coming from a POSIX environment and
assuming that Windows is going to honor its conventions. I personally don't
bother with the C library very much. I deliberately avoid it. Its Win32/64
programming all the way with me. That too has its undocumented quirks, but
is better documented that the brief Java documentation for example. Windows
programming can be quite difficult. It is just that I've been around it for
so long.
Windows and Mac are not designed for people who are not dedicated to working
with these environments. I have experience in both of them. You may want to
use Microsoft Visual C++ to access the Microsoft .NET Framework rather than
bother with the C library. There is a Haskell library designed to help you
access the Microsoft .NET Framework directly from Haskell on Windows. Even
so, you may want to work with C++ to do this because the Microsoft
documentation will not explain to you how to do this in Haskell.
--------------------------------------------------
From: "Andrew Coppin"
Erik de Castro Lopo wrote:
There are bigger problems than that. The Microsoft compiler still doesn't support large chunks of the 1999 ISO C Standard.
Seriously? OK, well that's news to me. I was under the impression that practically all C compilers in existence support the same set of features. (Although I'm sure each one probably has a few non-standard additions too.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Andrew Coppin wrote:
Erik de Castro Lopo wrote:
There are bigger problems than that. The Microsoft compiler still doesn't support large chunks of the 1999 ISO C Standard.
Seriously? OK, well that's news to me.
Yes, seriously: http://www.mega-nerd.com/erikd/Blog/Windiots/ms_c99.html That list is not complete, just what I felt was stuff that was hard to do without. The lack of a standards conforming snpirntf is particlularly painful.
I was under the impression that practically all C compilers in existence support the same set of features. (Although I'm sure each one probably has a few non-standard additions too.)
With the GNU compilers (and I suspect most other) the non-standard features can be switched off. For the GNU compilers -std=c99 or -std=c89 allows the user to pick which standard they are compiling to. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On Dec 8, 2009, at 11:00 AM, Andrew Coppin wrote:
In other words, "Windows needs to become just like Unix". Not going to happen.
I have the use of a dual-boot MacOS/Vista laptop. "Subsystem for Unix-based applications" is a Microsoft download. It means I can compile C programs using 'cc' or 'c89', and yep, it's VS behind that curtain. It's an alternative to MinGW or CygWin that might be worth exploring. Visual Studio remains a separate product, but SUA is free.
participants (6)
-
Andrew Coppin -
Erik de Castro Lopo -
John D. Earle -
John Lato -
Maurício CA -
Richard O'Keefe