[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: coreutils rm - win32 native port
RE: coreutils rm - win32 native port
Wed, 15 Aug 2007 15:30:47 +0300
First Bob, then Eric :)
This policy explains why not initiate non-gnu-os porting (for which I have a
good answer: I need it) - but not why to *reject* them.
> remove.c was almost completely re-written using the native WIN32
> API. It now compiles with MSVC 2005 and works well.
The reality is quite the opposite of what you've said: have you looked in
remove.c ? It's full of sun's proprietary functions: openat() and similar;
emulating them is a terrible performance hit (200+% more system calls is my
estimation) and a headache. Had it been written with only opendir() and
unlink(), it wouldn't have had to be re-written. Another thing is the code
complexity in remove.c - I didn't quite understand why is it so big and
complicated; but this is probably just me..
I really could have re-written it using opendir() and unlink() - but win32
was my main concern here.
( Here, opendir() and unlink() would serve a nice example of a near-portable
API: it provides access to the underlying implementation using a DIR* opaque
structure; yet it uses proprietary "dirent" for file information. )
> -----Original Message-----
> From: Eric Blake [mailto:address@hidden
> Sent: Wednesday, August 15, 2007 06:51
> To: Aviad Lahav
> Cc: address@hidden
> Subject: RE: coreutils rm - win32 native port
> > - I tried Mingw's MSYS now; it suffers from the problems similar to
> > cygwin's: needs to be installed and needs a DLL.
> MSYS is a collection of mingw apps along with a shell; it encompasses
> several features including file name munging, above what a simple
> mingw application normally does. Using mingw does not require
> using MSYS. But complaints about MSYS or mingw are better
> directed at their mailing list, rather than here.
> > - Why shouldn't coreutils accept native win32 ports?
> Because the GNU Coding Standards do not require bending backwards
> to support proprietary systems. It is counterproductive to our
> to add #ifdefs all over the portable code just for one non-free
> that does not believe in following standards.
> > GNU make does.
> Only because someone volunteers to maintain it.
So, if I volunteer to maintain win32 support, would coreutils accept the
> > I think
> > native win32 support should be an objective of the project;
> And you are entitled to that opinion. However, Jim, as the primary
> maintainer, is of the contrary opinion that upstream coreutils is
> to maintain if it sticks to non-proprietary, portable APIs, and I agree
> with him.
First, I tend to agree with GNU's approach here.
Second, I think there's a confusion here: Posix/unix-like API is indeed
non-proprietary, but it's *not portable* by no means; a portable API means
it abstracts away any underlying OS objects using undefined structs and
opaque void* types.
for instance (a) it assumes a user/group identifier is always a uid_t/gid_t
(integral type), (b) no support for arbitrary-file-system per-file
information, such as hidden/system attribute on win32 or file version on
VMS, hence there's no way of copying it from file to file (cp -p is hurt
here). (c) It assumes the underlying FS has inodes; I guess cp's hardlink
detection breaks when a linux machine mounts an NTFS.
(d) as a design principle, it not only lacks extensibility mechanism, it
explicitly precludes them. This is more of an anti-portability approach.
I think a truly portable (and therefore extensible) OS API is a real need of
the GNU community. A well-designed API could make lives much easier for
everybody - users and maintainers.
> > if not, the
> > situation I described before won't be solved: win32 users will have
> > choices of non-standard, not-entirely-working ports.
> That all depends on your definition of non-working. In my opinion,
> the cygwin port of coreutils works just fine (but I am a bit biased,
> as I maintain the cygwin port).
I don't think you're the responsible for cygwin's non-working stuff. Such
problems are inherent to cygwin as it supplies a posix API - which is not
portable, as I said above. Cp -p could never preserve hidden file attributes
using a posix emulation layer - to mention one burning example.
> Eric Blake