bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] remove windows subdirectory


From: Micah Cowan
Subject: Re: [Bug-wget] remove windows subdirectory
Date: Fri, 11 Jun 2010 14:05:11 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

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/



reply via email to

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