RE: [Bug-wget] remove windows subdirectory

[Christopher G. Lewis]

The addition of Automake and gnulib were what broke the Windows native
build.  There was no consideration to keeping the Windows build in sync,
and I wasn't able to keep up with the changes that Micah was doing to
the basic build process - when questioned, "we'll fix it later" was all
I was hearing.  

Around the same time, it was discovered that NTLM authentication only
worked with NTLMv1 not NTLMv2 and I spend a couple of weeks
(unsuccessfully) trying to get that working.  

My life got busy, so I just gave up trying to keep up.


Christopher G. Lewis 
http://www.ChristopherLewis.com


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of Micah Cowan
Sent: Friday, June 11, 2010 4:05 PM
Cc: address@hidden
Subject: Re: [Bug-wget] remove windows subdirectory

On 06/11/2010 08:46 AM, Hrvoje Niksic wrote:
> "Christopher G. Lewis" <address@hidden> writes:
> 
>> There certainly is something to be said about having a native windows
>> client.
>>
>> The trend to Cygwin and MinGW for WGet is pretty depressing given the
>> past history of wget.
> 
> I believe the executable produced by the MinGW build process *is* the
> native Windows executable.

Yup.

> It would be nicer to Windows developers if a native build environment
> were continued to be supported, but Windows is hardly the primary
> platform for Wget, so a compromise that makes lives of the majority of
> the developers easier is not unthinkable.
> 
> Is there anyone on this list who even is even using the makefiles in
the
> windows subdirectory at this time?

Well, for "at this time" it'd be nearly impossible, of course, since
they're all broken.

Maintaining separate Makefiles for Windows and trying to keep them in
step with the Automake-generated ones is an exercise in frustration.
Especially since all the gnulib code basically assumes an autotools
environment, and trying to use the gnulib code outside of that
environment is crazy frustrating. Certainly Giuseppe shouldn't have to
deal with it, and I have the suspicion that were a "Windows maintainer"
approved, they might have trouble reacting to each new change necessary
to keep it "current". (Each new "gnulib-tool update" on the part of
Giuseppe would take, what, a minute for Giuseppe, and potentially hours
for the Windows maintainer).

I suspect the best way to deal with this might be to eliminate the
"windows" directory, and if someone would like to maintain the "native"
ones, they can maintain it as a separate add-on package. That way
neither of us are tied to each other, and the native-Windows folks can
work in reaction to major releases, if they choose, rather than trying
to keep in lock-step. In the meantime, if we keep MinGW support working,
then we can supply our own Windows binaries if need be, and even supply
them in ".zip" form on ftp.gnu.org potentially.

-- 
Micah J. Cowan
http://micah.cowan.name/