bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] ftruncate: mark module as obsolete; even MinGW provides it,


From: John W. Eaton
Subject: Re: [PATCH] ftruncate: mark module as obsolete; even MinGW provides it, now
Date: Fri, 9 Apr 2010 13:02:15 -0400

On  9-Apr-2010, Jim Meyering wrote:

| Paolo Bonzini wrote:
| > On 04/09/2010 12:48 PM, Jim Meyering wrote:
| >> Of course, if you have some precise -- and useful enough to count as a
| >> reasonable porting target -- development environment in mind for which
| >> this particular replacement is required, let us know.  That would serve
| >> as reason enough to defer or even cancel the planned removal.
| >
| > That's what Bruno said, MSVC.  All functions in mingwex are not
| > provided by MSVC.
| 
| Yes, I saw that.
| However, given its limitations and the lack of interest we've seen
| so far, it fails to qualify as "reasonable".
| 
| On the other hand, if you tell us that you have hundreds
| of patches that make gnulib work on MSVC, and have been
| waiting for the right time to post them... ;-)

Hi,

I don't have any pending patches for gnulib with MSVC, but I am using
gnulib in Octave now and I have some users who want to be able to
compile with MSVC.  I encourage people to use MinGW because I'd rather
see people using free software tools and participating in our
community, but I try to not actively get in the way either because I
don't think that helps much.

I am personally really happy to be using gnulib because I don't want
to have to maintain my own collection of portability functions.  It's
much better to be doing this job once and sharing it among many
projects.

However, when I started using gnulib, it caused a fair amount of
disruption for people building Octave on non-GNU systems.  Thanks to
everyone working on gnulib (but especially Bruno for his work to make
gnulib play nicer with C++) the situation is much better now.

But at first, the users who were most affected by the transition had
some difficulty seeing the advantages of gnulib.  I'm afraid that they
started to think I was actively getting in the way by breaking Octave
on non-GNU systems.  The worst problems were encountered on Windows
with MSVC. The person who builds Octave most frequently on this system
was not happy that switching a library that was supposed to improve
portability did not work as well as the portability hacks we had been
using.

Maybe I'm wrong, but it seems to me that there is quite a bit of
overlap with MinGW with a small number of things that are needed for
MSVC but not MinGW.  Would it cause a lot of trouble to accept patches
for MSVC and preserve code for MSVC even when it is no longer needed
for MinGW?  We could certainly tell people that unless someone steps
forward to be the maintainer of code for the MSVC-specific parts of
gnulib, then there are no guarantees about whether it works and if
it breaks they get to keep the pieces.

jwe




reply via email to

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