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
