On 9-Apr-2010, Paolo Bonzini wrote:
| On 04/09/2010 11:04 AM, Bruno Haible wrote:
| > Indeed. But since mingw has it but MSVC doesn't, this raises the
| > question: how important is the MSVC porting platform (use Microsoft's
| > compiler and include files [proprietary but downloadable at zero cos
Hello,
* Bruno Haible wrote on Fri, Apr 09, 2010 at 11:04:38AM CEST:
> [MSVC] On one hand,
> there have been attempts to add support for this platform to libtool.
For what it's worth, there is fairly well-working support for MSVC in
Libtool's pr-msvc-support branch (as in: it passes most of the
t
John W. Eaton wrote:
...
> 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 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 req
On Apr 9, 2010, at 2:04 AM, ext Bruno Haible wrote:
> Hi Jim,
>
>> I'm marking ftruncate as obsolete, prior to removing it altogether.
>> I am removing the few uses from coreutils, too.
>> It's been in mingw for quite a while:
>>
>>$ cvs log mingwex/ftruncate.c
>
> Indeed. But since mingw
On 04/09/2010 01:04 PM, Jim Meyering wrote:
Yes, I saw that.
However, given its limitations and the lack of interest we've seen
so far, it fails to qualify as "reasonable".
I agree that we shouldn't declare it supported, but I don't think it's a
good reason to remove code that works.
On the
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 rea
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 cance
Bruno Haible wrote:
> Hi Jim,
>
>> I'm marking ftruncate as obsolete, prior to removing it altogether.
>> I am removing the few uses from coreutils, too.
>> It's been in mingw for quite a while:
>>
>> $ cvs log mingwex/ftruncate.c
>
> Indeed. But since mingw has it but MSVC doesn't, this raise
Paolo Bonzini wrote:
> On 04/09/2010 11:04 AM, Bruno Haible wrote:
>> Indeed. But since mingw has it but MSVC doesn't, this raises the
>> question: how important is the MSVC porting platform (use Microsoft's
>> compiler and include files [proprietary but downloadable at zero cost
>> from Microsoft
On 04/09/2010 11:04 AM, Bruno Haible wrote:
Indeed. But since mingw has it but MSVC doesn't, this raises the
question: how important is the MSVC porting platform (use Microsoft's
compiler and include files [proprietary but downloadable at zero cost
from Microsoft's web site], with possibly a wrap
Hi Jim,
> I'm marking ftruncate as obsolete, prior to removing it altogether.
> I am removing the few uses from coreutils, too.
> It's been in mingw for quite a while:
>
> $ cvs log mingwex/ftruncate.c
Indeed. But since mingw has it but MSVC doesn't, this raises the question:
how important i
00:00:00 2001
From: Jim Meyering
Date: Fri, 9 Apr 2010 10:44:23 +0200
Subject: [PATCH] ftruncate: mark module as obsolete; even MinGW provides it, now
* modules/ftruncate (Status): Obsolete.
(Notice): Say that.
* doc/posix-functions/ftruncate.texi: Don't say MinGW lacks it.
http:
13 matches
Mail list logo
