bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] Thoughts on Windows support


From: Micah Cowan
Subject: [Bug-wget] Thoughts on Windows support
Date: Wed, 09 Sep 2009 14:16:50 -0700
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, I've played around a bit with building wget on Windows, and here's
what I've seen so far.

Switching to the use of automake and gnulib in the 1.12 sources seems to
have potentially simplified the job of maintaining support for Windows
builds via MinGW, if one is also using MSYS. You can generate the
Makefiles directly from the included Makefile.in's by running the
configure script, which is a lot handier than maintaining a separate
"Makefile.src.mingw", etc.

I haven't gotten a successful build this way, yet, but I didn't spend a
lot of time on it, either. However, all the gnulib stuff compiled (and
linked, as libgnu.a) right off, and it was precisely gnulib that was
giving me headaches with my limited experiments with Visual Studio (and,
I would expect, with MinGW via our Makefile.*.mingw files). In
particular, much of gnulib (especially the header files) clearly expect
to have been processed by ./configure; I expect that they're
specifically intended for use with MinGW/MSYS (well, and Cygwin, obviously).

If I can manage getting MinGW builds this way, then I believe I'll be
inclined to only directly support MinGW builds, "officially", as the
maintenance burden will be vastly reduced if I can continue to leverage
the same build infrastructure I'm already used to on GNU and Unix
systems. Visual Studio builds would then continue to be maintained
"contrib-style", allowed to flourish or falter depending on the outside
love it receives. :)

The "./configure" script appears to be costlier to run on Windows than
it is on Unix, so it would probably make sense to continue to supply
pre-generated Makefiles in the distro (this might also eliminate the
need for builders to require MSYS, leaving just MinGW and MinGW-make);
the difference would be that we hopefully wouldn't have to maintain them
as separate entities, and can do all modifications - for Windows and for
Unix - in the Makefile.am's and configure.ac.

Perhaps maintaining Visual Studio builds will also be much easier once
we have working Makefiles for MinGW, and they could just be modified a
bit to work with Visual Studio, I dunno... Ideally, if we could get the
configure script, running under MSYS, to support some extra command-line
options that add the right magic to the Makefiles for use with
nmake/MSVC, that'd be awesome. Dunno how feasible that is, though, or
even whether autoconf/automake-generated Makefiles can be made usable
with nmake... I have doubts. At the very least, though, working MinGW
Makefiles would provide a decent template for those who bravely maintain
Visual Studio support (Chris Lewis, is that still you?).

Gisle, you submitted some light source-level changes for MinGW builds to
be working again, but as some others pointed out the current Makefiles
still don't build on MinGW. Are you perhaps already using this proposed
method, yourself, to build MinGW? Or where do the source-level changes
come from? :)

One final thought: configure.BAT has an option for Borland C. Is anyone
still building Wget (since 1.11) with Borland C?

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqoG0EACgkQ7M8hyUobTrFRHwCbBssdFpDQbfffG9WzLr+BEPw/
sjMAn26LjAugFRoXwXCmHjkW8mDHi4LS
=CYRG
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]