I'm coming in on the tail end of the conversation and haven't had time to keep up with the list of late, so please bear with me.
Phil wrote: >GNU gzip - http://www.gnu.org/software/gzip/ - seems to be >actively maintained, unlike the stuff at gzip.org, but it depends on Gnulib, which >in turn seems to depend on the MinGW runtime. >From what I know of the original MinGW project Mumit Khan set it up to use the CRTDLL library commonly available on all Windows machines as the runtime. MinGW later switched to the MSVCRT library. These are Microsoft dlls distributed on all Windows machines. The idea was for MinGW compiled programs to be able to run on any Windows machine without having to distribute runtime libraries that might be under licenses that could make them difficult to distribute. For instance, a GNU GPL license would mean you'd need to distribute your source code as well (which is what happens when you use Cygwin as your build environment and compiler suite). First, unless you have a need for gzip specifically, I'd have a look at porting bsdtar. There's a Windows port in the mingw files and it's been ported from a BSD version. So, it's cross-platform and it's not so tied into the GNU libraries. It also provides the functionality to unarchive (and I believe archive as well) gzip files. 7za from the 7zip project also handles gzip files if you just need a tool to access them and I think it'll build with Visual C/C++. I personally use these two instead of gzip all the time anyway. Second, I haven't looked at the gnulib code, but there must be a way to get it to port to other Windows compilers. You may just have to provide the missing functionality. That's exactly what projects like gnuwin32 did. That project even goes as far as to provide its own glibc. Although, I find the gnuwin32 glibc rather buggy when included directly in projects, using pieces from it when licensing is compatible in order to support missing functionality works really well with some projects. I also wanted to weigh in on the shallow-forking thread. If you do get something to build and it is an active project, don't just fork it. Send your changes back to the original developer(s). I've run across a lot of projects no longer actively supported and even one project where the developer was adamant against not having anything to do with a Windows port, but for the most part developers have been really nice about accepting patches for other compilers back into their original projects. How do you think so many projects ended up building with MinGW now? When I started using it, nothing built with it. I remember picking 4 libraries I thought a lot of developers might use and sending each project a makefile or relevant patches for MinGW. If Visual C/C++ has a GNU like command line front end and I thought there was something like this already in existence with the SFU/SUA project, you can download msys and other Unix like tools (cp, sed, etc.), change some environment variables and build some projects using Visual C/C++. I do exactly that with the Watcom compiler. Watcom is nothing like MinGW, but they have a wrapper called owcc and it can be used in conjunction with various GNU tools. If anyone's interested, I have information on how to set up msys for MinGW or Watcom here: http://www.distasis.com/cpp/msys.htm There's no reason why the same technique won't work for other compilers. I'll also mention I have a FAQ on MinGW (set up, usage, etc.) here: http://www.distasis.com/cpp/mingw.htm I've been having nothing but trouble since the MinGW project switched to mingw-get for installations, so I still have some dated scripts on setting it up using wget. By the way, there's a standalone version of wget at the gnuwin32 project http://gnuwin32.sourceforge.net/packages/wget.htm and two standalone versions of bash, a DOS version at the djgpp site and Windows version based cygwin at http://www.steve.org.uk/Software/bash/ With these programs you can scaffold downloading other utilities and programs you need to put together a build environment. I've done it before with MinGW and OpenWatcom. With regards to porting/forking, it would be nice to try not to reinvent the wheel. I have a lot of patches at my web site for various programs that come from a POSIX environment that I wanted to build on Windows. The gnuwin32 project has lots of patches to get things to properly build on Windows as well. Someone mentioned libjpeg. I took a look at building that on MinGW from scratch. The gnuwin32 project puts in several fixes and additions to make it work properly on Windows. It didn't even pay me to try to build it straight from the source without those patches as there were too many things that just did not work properly on Windows without them. While I'll admit there are differences between MinGW and Visual C/C++, a lot of patches I end up making when I port to Windows are Windows specific, not compiler specific. I also try to go with software that's cross-platform by nature or written well. It makes it much easier to port. If you check the OpenWatcom wiki, there's information on building pdcurses, fltk and wxwidgets (all cross-platform UI libraries). They have a port of GTK+ in the works too. OpenWatcom isn't any more like MinGW than Visual C/C++. So, if it can build those libraries, Visual C/C++ should be able to as well. I built dialog using pdcurses with both MinGW and OpenWatcom, most of what I added to patch it was exactly the same for both with just a few minor differences. Garrett mentioned: >With ones that don't have any vcxproj files, we just need to get it to compile. >Any. Way. We. Can That's the hard part. If you can get a makefile from MinGW or someplace else, then you can figure out how to get a decently written program to port. However, getting to the point where you have a makefile (or know what files you need to build with what type of compiler and linker switches) is the worst part of the job. Sometimes I'll find myself tweaking a configure file just to get it to produce a makefile even if it doesn't have the right dependencies or options on the system. If you can get to a makefile, you can usually work with it. I've always found the whole GNU autotools/configure way of doing things a nuisance. The other nuisance in porting is the GNU tools to handle internationalization. They're also done in some cases with a bunch of scripts and macros and need a very specific GNU toolchain. It can be helpful to check which programs build for BSD systems. They're trying to get away from the GNU toolchain as well. It's also helpful to look for alternative programs that are more cross-platform friendly. By the way, there's a port of an X Windows server natively to Windows at http://www.straightrunning.com/XmingNotes/ Someone also attempted to port some of the X Windows libraries to Windows: http://wiki.winehq.org/WineOnWindows#head-2ff2342a7bfab9d81c2be136a88f4b74921323f1 It would be nice to get a Windows port working so that some of the programs that are designed to work specifically with X libraries would work natively with Windows. Right now, the only way to run them is with environments like Cygwin or SFU/SUA. If anyone's interested, my patches page with patches for various programs is at http://www.distasis.com/cpp/patches.htm I'm working in my free time on trying to automate building and patching of cross-platform Open Source programs without having to worry about getting locked into one particular compiler or one particular platform. That's what got me interested in the Coapp project in the first place. Sincerely, Laura _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
