coapp-developers team mailing list archive

[ml@xxxxxxxxxxxx]

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