RE: coreutils rm - win32 native port

[Aviad Lahav]

First Bob, then Eric :)


>
http://www.gnu.org/prep/standards/html_node/System-Portability.html#System-P
ortability

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
> philosophy
> to add #ifdefs all over the portable code just for one non-free
> platform
> that does not believe in following standards.
> 
> http://www.gnu.org/prep/standards/html_node/Compatibility.html#Compatib
> ility
> http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-
> Philosophical-Consideration
> 
> > GNU make does.
> 
> Only because someone volunteers to maintain it.



So, if I volunteer to maintain win32 support, would coreutils accept the
changes?



> 
> > 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
> easier
> 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
> endless
> > 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